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Te TNERODUCTION 


A. BACKGROUND 

Model management systems (MMS) can be effective tools 
within an organization’s information system. Top-level 
management can use "what if" type models and corporate data 
for strategic decision making. At lower levels, modeling may 
aid in the optimization of an assembly process using produc- 
tion data as inputs. 

Management's awareness of the need for MMS has increased 
due to several factors currently facing the management 
Science and operations research (MS/OR) communities [Ref. 1: 
ep. 547-549]: 

- MS/OR activities are not highly productive. 

- Managerial acceptance of model-based assistance is low. 

- The micro-computer revolution provides the medium for 
greater productivity and acceptance of MS/OR applica- 
tions. 

- The advances in database management systems (DBMS) 
technology provide a suitable interface for the high data 
demands of MS/OR software. 

- The popularity of spreadsheet modeling proves that many 
people have the potential to construct useful models 
given the appropriate tool. 

E ressor A. M. Geoffrion of UCLA proposes structured 


modeling as a theoretical base from which these issues can be 


addressed [Ref. 1]. 


The main purpose of this thesis is to design and imple- 
ment a prototype of a graphical user interface for an MMS 
based on the principles of structured modeling. Of interest 
also will be the refined requirements specifications based on 


the implementation of the prototype system. 


er SERUSTUREDTMODERTNG 

Structured modeling provides the theoretical foundation 
for a new generation of MMS. Its goal is to increase the 
productivity and acceptance of MS/OR applications throemen 
greater usage and understanding by model practitioners and 
non-practitioners alike. Structured modeling allows for the 
inclusion of several desirable features necessary for an 
effective MMS [Ref. 1: p. 550]. 

The conceptual framework of structured modeling provides 
for the delineation of a wide range of MS/OR mathematical 
models in a single representation format. The representation 
of a ee model is independent of both its solution 
operators and its required data. The representation format 
lends itself to computer implementation with a graphical user 
interface. The independence of a model and its data allows 
the integration with current database technology. Finally, 
structured modeling provides support for the complete life- 


cycle of a model [Rert. 250p Su 


© PROGRAMMING ENVIRONMENT 

The hardware configuration for the implementation of this 
system is an IBM-PC, or compatible, equipped with an enhanced 
graphics adapter (EGA) card. The selection of this config- 
REAL NON, vice a Mainframe configuration, is due to the 
widespread use of micro-computers throughout many organiza- 
tions. The higher resolution graphics attainable from the 
EGA card improves the aesthetic quality of the interface. 
These requirements are not excessively restrictive and are 
comparable with limitations imposed by commercial software 
Preducts. 

The programming environment for the system is the 
Lattice-C compiler along with the HALO graphics package and 
the PC ORACLE DBMS. The Lattice-C compiler gives programming 
a rsat laty not eundeinwmany micro-computer-language 
implementations. The HALO graphics package offers a complete 
BOT n Obahighe speed graphics routines designed for the 
Lattice-C compiler. The selection of the PC ORACLE DBMS is 
Bro role: (1) its support of SOL (Standard Query Language) 


and (2) compatibility with the Lattice-C compiler. 


D: SUMMARY 

The purpose of this thesis is to implement a prototype 
graphical user interface for an MMS based upon the principles 
Ee tructured modeling. The prototype will be used to 
evaluate the initial requirements specifications for the 


interface. Errors and problems encountered in implementation 


of the prototype will be reported. Refined system require- 
ments will also be presented. Recommendations for further 
research and implementation of the interface will be dis- 
cussed. Specific emphasis will be placed on whether to 
continue the system implementation from the prototype or 
begin anew using conventional structured analysis and design 
techniques. 

Chapter II provides an overview of structured modeling. 
The basic descriptions of a structured model's elements, 
representations, and underlying principles are discussed. An 
example of a structured model is constructed to reinforce the 
theoretical concepts. 

Chapter III presents the initial system requirements and 
proposed design of the graphical user interface prototype. 
The data structures and critical modules are detailed in this 
chapter. 

Chapter IV discusses problems that were encountered 
during the implementation of the prototype. A discussion of 
refinements to the initial system requirements, reusability 
of the prototype, and integration with other concur rome 
efforts is included. 

Chapter V concludes this thesis with as symopsisio K 


results, observations and recommendations for future study. 


jJ UCTU ODETLING 


A. INTRODUCTION 

Two factors hinder the proliferation of management 
science and operations research (MS/OR) modeling: the low 
productivity of MS/OR activities and a lack of managerial 
acceptance of modeling [Ref. 1: pp. 547-549]. The factors 
interrelate in that low productivity amplifies management's 
reluctance to accept models. 

Low MS/OR productivity is inherent in the current 
modeling technology. Present modeling practices that 
adversely affect MS/OR productivity are: 

- The redundancy of effort needed to place models in the 
required representation formats. Typically, external 
requirements force the generation of three separate model 
representations. Communication with non-MS/OR personnel 
mandates a logical model representation. A mathematical 
representation is required for analysis. Finally, 
computational complexity and data requirements neces- 
sitate a representation that is computer-executable. 

eW difficulty of interfacing logical and mathematical 
model representations with available modeling software. 
Most MS/OR software products use no interface standards, 
accept only one type of model schema, and do not support 
the entire modeling life-cycle. 

One might expect that the lack of managerial acceptance 
of models is due to models not capturing reality adequately, 
however, this is not generally the case. The issue of 


acceptance is largely a matter of management’s reluctance in 


becoming dependent on MS/OR personnel. Modeling 


practitioners do not convey the Structure ran eu 
formats that are easy to comprehend. Therefore, the opera- 
tion of the model is not understandable and results must be 
blindly accepted. This situation is not conducive to promo 
management. 

The quest for better MS/OR productivity and acceptance, 
however, is far from hopeless. Several recent technological 
advances present opportunities for improvement in modeling 
techniques and comprehension [Ref. 1: pp. 548-549]. The 
increased availability and usage of micro-computers provides 
an instrument to raise productivity. Accessing data through 
database management systems allows use of a single data model 
to serve many applications. Finally, the overwhelming 
popularity of spreadsheet software suggests greater accep- 
tance and demand for models when represented in an unders- 
tandable format. 

A new generation of modeling systems must be developed 
that resolve MS/OR and management conflicts and incorporate 
the new technologies. To effectively address these issues, 
the new systems should possess the following features 
(RST T pa DAD 


l. A single model representation supporting logical views, 
mathematical analysis, and computer execution. 


2. A model representation sufficiently general to encom- 
pass a majority of MS/OR models. 


3. An interface that supports the entire moderin Thi i 
Cycle 


BEE teraimiero-eoömpüter version with a modern 
user interface. 


5. Integration with a database management system. 
6. Instantaneous solutions in the tradition of spreadsheet 
software. 


Structured modeling lays the foundation for a modeling system 
providing all of these features. 

This chapter gives a basic description of structured 
modeling. The thrust is to define terms and present the 
underlying concepts of structured modeling. A simple 
transportation model will be used to reinforce and supplement 
the explanation of concepts. The intention of this chapter 
MINO LO Cover Structured modeling in its entirety. Readers 
requiring a comprehensive treatment of structured modeling 
EMA consult the research of Geoffrion [Ref. 1: pp. 552- 


meee (Ret. 2: pp. 2-1 to 2-101]. 


Pee RILNCIPLES OF STRUCTURED MODELING 
Structured modeling is a unified modeling framework 
based on acyclic, attributed graphs to represent cross- 
references between elements of a model, and hierarchies to 
represent levels of abstraction. [Ref. 3: p. 4] 
A structured model consists of three basic structures: an 
elemental structure, a generic structure, and a modular 
ENwUccure. 
A structured model is expressed in terms of five types of 
elements: primitive entities, compound entities, attributes, 


functions, and tests. Every structured model contains at 


least one primitive entity. A primitive entity defines the 


existence of an object. Its description makes no reference 
to a value or magnitude. Compound entities refer to other 
entities, usually primitive entities, to define a new and 
unambiguous entity. Attributes associate values and proper- 
ties with entity type elements. Variable attributes are 
extensions of attribute elements. The values of a variable 
attribute are likely to change and come under the control of 
a model solver. The value determination of a function 
element is in terms of a rule or equation. A test element is 
essentially a function element returning a boolean or 
true/false value. 

A model's elemental structure is defined as a non-empty, 
finite, closed, acyclic collection of model elements [Ref. 3: 
p. 4]. Every element within an elemental structure, except 
primitive entities, has a calling sequence. An element calls 
another element if the second (or called) element is iene 
calling sequence of the first element. Calling sequences 
provide a means of capturing the cross-references between the 
elements of a model. An acyclic elemental structure will 
have no element which directly or indirectly calls itself. 
Acyclicity prevents a model from being indeterminable 
[Ref. 2: p. 2-4]. The graphical representation of the 
elemental structure contains all the model's elements and 
accurately depicts each elements calling sequence. 

The generic structure of a model is an abstraction of the 


elemental structure. Similar element types are grouped into 


genera (or partitions) based on generic similarity. Each 
element belongs to only one genus (singular of genera). 

Sr. 1ısfaetionser generic similarity occurs if all members of a 
genus are of the same element type, have an equal number of 
calling sequence segments, and make calls to the same genus. 
The graphical representation of the generic structure, the 
genus graph, shows each genus as a node and the relationships 
between the genera as directed arcs between the appropriate 
nodes. 

The modular structure provides a tree-type representation 
of a model which serves as an aggregation of the generic 
structure. All terminal nodes in the structure are genera 
and all non-terminal nodes are modules. Modules are meaning- 
ful groupings of genera. Modular structures satisfy the 
conditions of monotone ordering.  Monotone ordering requires 
that modular structures fit an indented list format with no 
genera making forward references to any other genera. This 
implies that a module is essentially a hierarchically ordered 


list of genera. 


©, EXAMPLE: THE TRANSPORTATION MODEL 

The best way to gain an understanding of structured 
modeling is with an example. This section uses the transpor- 
pon model to reinforce the definitions and concepts of 
structured modeling. The analysis of the transportation model 
begins with identification of the elements in the model. The 


elemental, generic, and modular structures will be derived 


and illustrated. In addition, reachability and adjacency 
matrices are introduced as adjuncts to structured modeling. 
An alternative to the graphical representation of structured 
models is also presented. 

The transportation model used for this example was first 
used by Geoffrion [Ref. 2: pp. 2-70 to 2-71]. FPE PE 
Statement is as follows: 

- Two production plants, one in Dallas and the other in 

Chicago, must supply goods to customers in Pittsburgm 


Atlanta, and Cleveland. 


- The production capacities of the Dallas ande mT EE 
plants are 20,000 and 42,000 units, respectively. 


- The number of units required by the customers in Pitts- 
burgh, Atlanta, and Cleveland are 25,000, 15,000, and 
22,000, respectively. 

- The Dallas plant may supply each of the three cities, 
whereas, the Chicago plant may only supply the customers 
in Pittsburgh and Cleveland. 

= The cost of shipping from Dallas com 51cm = 
S23.50/unit; Dallas to Atlanta, $17.95/unic; Da- D 
Cleveland, $32.45/unit; ChicagowtGoPEN mo 
s7.60/unit; Chicago to Cleveland, $25.75) Gime. 

The purpose is to determine a solution that provides all the 
customers with the necessary amount of goods at the lowest 
possible toral cost. 

The easiest elements in a model to define are primitive 
entities. The following list shows that there are five 
primitive entities in the transportation modek 

- There exists a production plant in Data sm- 


- There exists a production plant in Chicago Se vage 


- There exists a customer in Pittsburgh mě 
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- There exists a customer in Atlanta (ATL). 

- There exists a customer in Cleveland (CLE). 
Notice there are no values associated with the primitive 
entities. Their existence is all that is necessary. The 
abbreviations in parentheses will be used to shorten future 
references in the definitions of new elements. 

There are five other elements in the problem that have no 
value and are existential in nature. However, since these 
elements reference primitive entities, they must be of the 
compound entity type. The definition of compound entities is 
as follows: 

Mere exists a Shipping link from DAL to PITT (LINK1). 
- There exists a shipping link from DAL to ATL (LINK2). 
here extses a shipping link from DAL to CLE (LINK3). 
Atnere exists a shipping link from CHI to PITT (LINK4). 
zerthere exzısts a shipping link from CHI to CLE (LINKS). 

Attribute elements associate values with entity type 
elements. There are numerous attribute elements in the 
transportation model: 

Si production capacity of DAL is 20,000 units (SUPPLY1). 
Sp reduction capaceıtyror CHI 787427000 units (SUPPEY2). 
SNE TE TA requires 25,000 units (DEMAND1). 

ESATD requires 15,000 units (DEMAND2). 

ERN DE requires 22,000 units (DEMAND3). 

moc cost of using LINKl1 is $23.50/unit (RATE1). 


EE cost of using LINK2 is $17.75/unit (RATE2). 
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- The cost of using LINK3 is $32. .4574]Hnm m E INA 
- The cost of using LINK4 is S7:60/0n T rAr CAPE 
- The cost of using LINKS is $25. 75/mnm Be sn B 

The transportation model also has a set of variable 
attributes. Each shipping link has an associated amount of 
flow (in number of units). The model solver determines the 
flow during model execution, therefore, flow is a variable 
attribute. The listing of variable attributes for ship r ia 
flow are: 

- There is a shipping flow over LINK1 (FLOW1). 
- There is a shipping flow over LINK? (FFON DE 
- There is a shipping flow over LINK3 (FLOW3). 
- There is a shipping flow over LINK4 (FLOW4). 
- There 1s a shipping flow over LINK5 (FLOWS). 

A function element exists in the transportation model 
which is the total cost of using each of the shippr aa 01m = 
Total cost is necessarily a function element due to its 
computational nature. There are also test elements to ensure 
that flows remain within the limits imposed by plant capac- 
ities and customer demands. Expressed in terms of the 
problem, the test and function elements are: 


- There is a total cost (TOT COST) which 1s OS SAA 
products of the individual flows and corresponding rates. 


- The flow leaving DAL cannot exceed SUPPLYI (T: SURP E 
- The flow leaving CHI cannot exceed SUPPLY2 (T:'SUPP P SE 
- The flow arriving at PITT must equal DEMANDI (T:DEMADBMEUMM 


- The flow arriving at ATL must equal DEMAND2 (T:DEMAND2). 
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- The flow arriving at CLE must equal DEMAND3 (T:DEMAND3). 

The construction of the elemental structure involves 
transcribing the calling sequences for each element into a 
graphical format. The graphical representation of an element 
may be a word, abbreviation, shape, or anything that is 
uniquely identifiable. The representation of the calling 
sequences are directed line segments. The base of the line 
segment identifies the called element and the head points to 
the calling element. Figure 2.1 shows the elemental struc- 
ture for the transportation model. The depiction of rela- 
tionships between elements are complete and accurate. 

A generic model structure is a generalization of the 
elemental structure. The elements in a model are grouped by 
generic similarity. For example, a genus called FLOW is 
formed by grouping all the variable attribute elements 
@eseribing the flow of goods across shipping links. Each of 
these elements have the same number of calling sequence 
segments to the same genus of elements. Thus, the grouping 
of FLOW1, FLOW2, FLOW3, FLOW4, and FLOWS satisfies generic 
Similarity requirements and forms a genus. Figure 2.2 shows 
the groupings of all the transportation model elements into 
their respective genera. The generic structure for the 
transportation model is shown as the genus graph in Figure 
EN rhe T:GENUS NAME is a convention for naming test 


genera. 
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Modules are the basis of module structures. A module is 
a meaningful grouping of genera. The definition of a 
meaningful grouping is a function of the use of the modular 
mne. Lhe only Tesiri ction on a modular structure is 
that it satisfies the requirement of monotone ordering. 
Figure 2.4 presents two acceptable representations of a 
modular structure, a tree structure and a modular outline. 
The ampersand preceding each module name is a structured 
modeling labeling convention. Note that all non-terminal 
Medes are modules, all terminal nodes are genera, and the 
monotone ordering is preserved. 

Structured modeling offers other miscellaneous constructs 
that are useful in the formulation and analysis of models. A 
vlew of a model is simply a generic structure with a ace 
replacing some of its corresponding genera. This construct 
can be useful in effective communication of models to non- 
MS/OR personnel by suppressing unnecessary details.  Reach- 
ability and adjacency matrices provide a quick reference for 
determining the inter-relationships between model elements. 
Figures 2.5 and 2.6 show the adjacency and reachability 
lI Ces for the transportation model's generic structure. 
The convention for reading the matrices is that the column is 
the calling element and the row is the called element. A "1" 
in an adjacency matri: means that the element in that row is 


in the calling sequence of the column element. Ina 
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reachability matrix, a "1" means that the row and column 
elements are related, with the column element being higher in 
the hierarchy. This alternative model conceptualization is a 
familiar software engineering analysis tool. 

Module and genus paragraphs supplement the graphical 
representation of structured models. The paragraphs provide 
more detailed interpretations than permitted graphically. 
Paragraphs are arranged and indented identically to modular 
outlines. A model schema iS a complete collection of 
paragraphs for an entire model. 

Structured modeling provides a highly developed syntax 
for genus and module paragraphs. The paragraph notation 


presents the model information in a compact form suitable for 


computer parsing. In Figure 2.7, the generalized paragraph 
notations are shown. Figure 2.8 is the schema for the 
transportation model. The following comments explain the 


meat onal conventions: 


- The module and genus names appear exactly as they do in 
the module structure. Both module and genus names should 
be short, descriptive, and upper case. 


- The "i" indicates that there is a symbolic genus index. 
The symbolic genus index is a referencing system to 
identify elements within a genus. For example, if DAL is 
PLANT, and CLE is CUST 3, then, LINK, refers to the 
transportation link between DAL and CLE. 


- The genus type is identified by an appropriate abbrevia- 
pron within a set of slashes. 


- The index set statement defines the population of 
elements associated with the genus. 


Zd 


PARAGRAPH TYPE 
MODULE 


PREMIITVEZENELTY 


COMPOUND ENTITY 


ATTRIBUTE 


PUNGEFON OR T 
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PARAGRAPH TITLE 


&MODNAME Interpretation 


GNAMEi /pe/ <Index Set Statement> 
Interpretation 


GNAME <i> (Generic Calling Sequence) 
/ce/ <Index Set Statement> 
Interpretation 


GNAME <i> (Generic Calling Sequence) 
/a or va/ <Index Set Statement> 
<Generic Range> Interpretation 
GNAME <i> (Generic Calling Sequence) 


/f or t/ «Index Set Statement» 
Generic Rule; Intepretation 


General Paragraph Notations 
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&SDATA There are some SOURCE DATA Concerning sources of 
supply. 


PLANTi /pe/ There is a list of PLANTS. 


SUP (PLANTi) /a/ {PLANT} :R+ Every PLANT has a SUPPLY 
CAPACITY Measured in units. 


&CDATA There are some CUSTOMER DATA. 
CUSTj /pe/ There is a list of CUSTOMERS. 


DEM(CUSTj) /a/ (CUST) :R+ Every CUSTOMER has a non- 
negative DEMAND measured in units. 


&TDATA There are some TRANSPORTATION DATA. 


LINK(PLANTi, CUSTj) /ce/ Select {PLANT} x {CUST} covering 
{PLANT}, {CUST} There are some transportation LINKS from 
PLANTS to CUSTOMERS. There must be one LINK incident to 
each PLANT, and at least one LINK incident to each 
CUSTOMER. 





FLOW(LINKij) /va/ {LINK} :R+ There can be a non-negative 
transportation FLOW (in units) over each LINK. 


RATE (LINKij) /a/ {LINK} Every LINK has a TRANSPORTATION 
e ORATE for use in $/unit. 


TOTAL COST(COST, FLOW) /f/ 1; SUMij (COSTij * FLOWij) There 
NEN TOTAL COST associated with all flows. 


T:SUP(FLOWi, SUPi) /t/ (PLANT); SUMj (FLOWij) < SUPi Is the 
meral FLOW leaving a PLANY less than or equal to its SUPPLY 
NOERCITY? This is called the SUPPLY TEST. 

MEDEM (ELOWj, DEMj) /T/ (CUST); SUMi (FLOWij) = DEM) Is the 


total FLOW arriving at a CUSTOMER exactly equal to its 
DEMAND? This is called the DEMAND TEST. 


Figure 2.8 Paragraph Schema: Transportation Model 
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- The generic calling sequence is the calling sequence of 
the genus. Notice that the genus symbolic indices äre 
used here. 

- The generic range provides the range of values associ- 
ated with a genus element. This is similar to declara- 
tion statements in programming languages. 


- The generic rule is the equation or rule used to assign a 
value to function and test genera. 


- The interpretation is a narrative description of the 
genus or module. This is similar to a comment in 
programming code. 
B SUMMARY 

Structured modeling provides the basis for a new genera- 
tion, general purpose model management system. The model 
representations afforded by structured modeling provide views 
that are comprehensible to management, support the detail 
required by MS/OR personnel, and are computer executes 
The graphical orientation of structured modeling allows for a 
computer-based implementation of a model management system 
with a state of the art user interface. The remainder of 
this thesis 1S concerned with the design of such an inter- 


face. 
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M S TEMP DESIGN 


A. INTRODUCTION 

Structured modeling establishes the foundation for a 
computer-based version of an operationally and functionally 
complete model management system (MMS). This thesis centers 
around the design and implementation of a graphical user 
interface to support this MMS. The prototyping development 
methodology was deemed the most practical for undertaking 
this project. The reasons behind this decision are presented 
in this chapter. System requirements specifications for the 
interface are also delineated and discussed. Finally, the 


overall system design is presented. 


E DEVELOPMENT METHODOLOGY 

A prime consideration in the design and implementation of 
any computer-based system is the selection of an appropriate 
development methodology. Until recently, the traditional 
life-cycle (TLC) approach to system development was the only 
widely acceptable option. The deterrent to using the TLC 
approach is that adequate requirements specifications must be 
defined prior to proceeding with design and implementation. 
The difficulty here is that completely accurate requirements 
Specifications are non-existent [Ref. 4: p. 57]. Therefore, 


determining when a specification adequately meets a user's 


a 


requirement is often a function of the deadline date for the 
TLC’s analysis phase. This leads to the development of 
systems that are not what the user wanted nor what the 
analyst intended them to be. 

The demand for large, high quality software systems 
has increased to the point where a jump in software 
technology is needed. Rapid prototyping is one of the most 
promising methods proposed for solving this problem. 
[Rep a] 

Prototyping, in its purest form, is the development of a 
disposable version of the intended system used to supplement 
the analysis phase of the TLC. However, prototype systems 
that are well controlled and documented can shorten the TLC 
methodology by allowing a jump from the analysis phase 
directly into system implementation (Ref. 6: p. 252] NN 
issue, in this thesis, is not whether prototyping shoe 
should not replace the TLC, but, that prototyping ee M 
viable means of systems analysis that helps solidify the 
Specification of a user's requirements. 

The selection of an appropriate methodology is best made 
prior to the beginning of a project. An unspecified approach 
to system development can only lead to confusion and the 
project's eventual death. This decision is based on the 
characteristics of the proposed system. Systems with known 
costs and benefits and requiring little or no innovation are 


well-suited for the TLC methodology. The prototip mii 


approach is most effective for systems containing new 
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technology, innovative software design, and uncertainty as to 
the operational benefits and costs [Ref. 6: p. 256]. 

The prototype methodology was adopted for use in this 
thesis for several reasons. The discipline of structured 
modeling is currently more theoretical than practical. As 
such, user requirements for the interface are very general- 
ized in nature. A prototype system would allow the formula- 
tion of a more exact set of requirements specifications. 
Another factor in the selection of the prototype approach was 
to prove the feasibility of implementing the system in a 
micro-computer environment. The main concern here was that a 
micro-computer would not possess the speed or memory neces- 
sary to execute the system in real-time. The final factor 
was to show that a model management system could be effec- 
tively integrated with a database management system at the 


rudimentary level of model entry and review. 


on ERSOUIDREMENTS SPECIFICATION 

The initial phase in the prototyping methodology is to 
Specify the system requirements. Unlike the TLC methodology, 
the prototyping methodology allows the definition of broad 
requirements specifications. The specifications become more 
metined as the prototype is constructed. This section 
presents the reguirements considered essential for a graphi- 
cal user interface to a model management system based on 


structured modeling. 
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The first requirement is that the system support real- 
time, graphical creation of structured models. The interface 
must provide a workspace for constructing both generic and 
modular structures. The workspace should allow assignment of 
meaningful names or labels to the various model elements.! 
Relationships between the model elements will be captured 
with directed line segments (or arcs) as stipulated in the 
concepts of structured modeling. 

The system should verify that the structure is allowable 
under the constraints imposed by structured modeling. If a 
generic structure is being created, the system ought to 
ensure that the model is acyclic and that there are no 
improper calling sequences (i.e., a primitive entity calling 
an attribute or a variable attribute calling a function 
a modular structure, the system needs to detect non-terminal 
model elements that are not modules and terminal model 
elements that are not genera. The intent is to verify 
adherence to the rules of structured modeling, not the 
accuracy or completeness of a model. 

The interface needs to allow the entrance of generic and 
module paragraph data. This portion of the interface must 
only request information from the user that cannot be 


extrapolated from the graphical representation. Paragraph 


lFor the remainder of this thesis, the phrase "model 
elements" will refer to genera and modules. The phrase 
"elements of a model" will connote the element definition 
given in the structured modeling chapter. 
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entries care then checked for syntactical errors and missing 
SEMA TON Upon completion of model construction, all 
data is assimilated, placed in the proper database format, 
and written to external memory. 

Another major specification for the system is the 
capability to generate genus graphs and modular structures 
from a database representation. The database representation 
is to have no references to graphical information. There- 
fore, the system must determine where to place model elements 
and the arcs representing the calling sequence segments. The 
goal is to re-create a functionally correct representation of 
the model that is aesthetically acceptable. The format for 
the graphical representations should be the same as that 
described for the creation of genus and module structures. 

In conjunction with the re-creation of graphical repre- 
sentations, is the requirement to view model information not 
captured graphically. This feature should allow the user to 
select a model element for which the corresponding paragraph 
data is then presented in a clear and concise format. 

Mbe third major system specification for the interface is 
the capability to edit a model. Model editing is to be 
allowed during the creation of a model and after its recall 
from a database. There should be a means to delete and add 
model elements. If a model element is deleted, the calling 
Sequence must also be deleted and the user prompted as to the 


disposal of the subordinate nodes. If an element is added, 
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the user needs to be prompted for the entry of the eken 
paragraph data. Editing of text within a paragraph descrip- 
tion should be allowed without affecting the graphical 
representation. 

A complete interface will also support miscellaneous 
structured modeling presentations. The user should be 
allowed to create specialized views of the genus graphs. 
Adjacency and reachability matrices are also a necessary part 
of the interface. 

The system requirements specifications just discussed are 
the starting point for the design and implementation of the 
prototype system. Under the TLC methodology, these require- 
ments would not be adequate for proceeding into the design 
phase. A large amount of additional time and effort is still 
required to define more exact specifications in either 
methodology. However, by prototyping the system, progress 
can be made on the implementation as specifications are 


better defined. 


D PROTOTYPE DESIGN 

The design and implementation of the entire system 
described in the requirements specifications was not under 
taken as part of this thesis. 60'Dell (Ref. 7] conducted 
cO MER e research concerning the on-line creation and 
editing of structured models and their subsequent entry into 
a database. The work presented in this thesis addresses the 


re-creation of model structures from the database 
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representation. The capability of viewing module and genus 
graphs is also discussed. 
l. Database Design 

A relational database representation of a structured 
model was adopted for this system. The database design was 
developed by Dolk [Ref. 3]. The basic premise of this design 
is that a structured model can be fully represented with two 
relations: the ENTITY relation and the RELSHIP relation. The 
ENTITY relation provides the description of a single model 
element. The RELSHIP relation allows representation of 
cross-referencing between model elements. The specific 
structures of these relations are presented in Figures 3.1 
and 3.2. 

The ENTITY relation uses ENAME and ETYPE as the key 
for referencing a particular record. ENAME, ETYPE, IDX, 
PDX STMT, GRANGE, GRULE, and COMMENTS are the ENTITY relation 
fields necessary to store model element paragraph informa- 
tion. The DNAME, DATE ADDED, LAST MOD, and NMODS fields are 
included for the administration of a multi-user model 
management system. Model elements not requiring all the 
information in the ENTITY relation leave the appropriate 
fields null (i.e., GRANGE and GRULE are null for a primitive 
entity representation). A SQL SELECT command is used to 
extract the correct tuple for a selected model element. 

The RELSHIP relation uses the RTYPE, ElNAME, ElTYPE, 


MAME, EZTYPE, and REL POS fields for representing the 
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Figure 3.2  RELSHIP Database Relation 


32 





relationships between model elements in generic structures 
and modular structures. The model element described by 
E2NAME and E2TYPE is subordinate to the model element 
referred to by EINAME and EITYPE. The ACG METHOD r K 
fields are used for multi-user MMS administration.  RTYPE, 
EINAME, EITYPE, E2NAME, and E2TYPE form the composite ke -= 
the RELSHIP relation. The RTYPE field holds either the value 
"contains" or "calls." An RTYPE value of "contains" r m 
to a modular structure relationship and a value of "calles 
refers to a generic structure relationship: 

Views of the ENTITY relation are defined for the 
various model element types. The view of each model element 
type contains the paragraph entries for that type as deline- 
ated in Figure 2.7. The SOL commands establishing these 
views are as follows: 

- For the primitive entity view: CREATE VIEW PE as SEE 
DNAME, ENAME, DATE ADDED, LAST MOD, NMODS, IDX, COMME 
from ENTITY where Fr; Es PE 

- For the compound entity view: CREATE VIEW CE as SEVER 
DNAME, ENAME, DATE ADDED, LAST MOD, NMODS, IDX, IDX STMT, 
COMMENTS from ENTITY where ETYPE = ‘CE’; 

- For the attribute view: CREATE VIEW CE as SELECT ONS 
ENAME, DATE ADDED" EAST, eb IT £ Tri, GRANGE, 
COMMENTS from ENTITY where ETYPE = 'ATT'; 

- For the variable attribute view: CREATE VIEW VA as 
SELECT DNAME, ENAME, DATE ADDED, LAST MOD, NMODS, 

IDX STMT, GRANGE, COMMENTS from ENTITY where 
EXPE = VA: 
- For the test view: CREATE VIEW TEST as SELECT DNAME, 


ENAME, DATE ADDED, LAST MOD, NMODS, TDZ SIMI R 111772 
COMMENTS from ENTITY where ETYPE = "TEST" 
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o ME EE view: CREATE VIEW FCN as SELECT DNAME, 
ENAME, DATE ADDED, LAST MOD, NMODS, IDX STMT, GRULE, 
COMMENTS from ENTITY where ETYPE = "FCN';. 

Views are also defined to capture the genus and module 
relationships represented in the RELSHIP relation. The SOL 
commands for the two views are: 

DORE calls” relationship: CREATE VIEW CALLS as 
SELECT EINAME, EITYPE, E2NAME, E2TYPE from RELSHIP where 
RTYPE = 'calls'; 

EE the contains relationship: CREATE VIEW CONTAINZ as 
SELECT ElNAME, ElTYPE, E2NAME, E2TYPE from RELSHIP where 
RTYPE = 'contains';. 

220401601 SEFUYCtUTé 

After establishment of the database representation, 
the design of the interface was undertaken. The first 
consideration in this process was the construction of a 
Em table control structure. This is required for proper 
operation of the prototype. 

A control structure is necessary that allows the user 
to access the various features of the interface. A hierar- 
Beil control structure provides this ability. At the first 
level, the user ıs given the option of selecting from model 
creation, recall, and editing as well as miscellaneous 
modeling and system“ functions. The “second level veemmands 
are those required in execution of the upper level task. 


EE control structure allows the incorporation of new 


features in as many levels as dictated functionally. 


“System une tons include directory changes, file 
deletion, renaming of files, etc. 
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SH Screen ves tem 


The screen format chosen reflects the design of the 
control structure. It is an adaptation from current commer- 
cial software products such as Lotus 1-2-3. There == 
of text across the top of the screen displaying information 
concerning the model being displayed in the workspace. A row 
of text across the bottom of the screen provides a quick 
reference to various program commands. The model workspace 
1s the area between the two rows of text. 

To accomplish the required screen display, a world 
coordinate system is first instituted. There are two 
advantages to using a world coordinate system [Ref. 8: 

p. 38]. First, the system refers to its own graphica = 
dinates rather than screen coordinates. This means that the 
System will be transferrable between display devices regard- 
less of their resolution. The second advantage is that all 
graphics is scaled to the size of the viewport. The biggest 
disadvantage of this approach is that the Halo graphics 
package does not allow text to be scaled in relation to the 
viewport. 

The screen construction begins by initially display- 
ing the required rows of tert. A viewport is then estab- 
lished which is the same size as the workspace. This al ewe 
refreshing, changing, or clearing the workspace without 


rewriting the rows of text. 
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4. Genus Icons 

The next design concern was the establishment of 
appropriate graphical depictions of the various model 
elements in a genus graph.  Geometrically shaped and uniquely 
colored icons are logical choices for this purpose. When 
combined with a textual label, there exist three visual means 
of identifying a particular model element. These icons are 
identically sized for easier positioning within the work- 
Space. 

An additional concern in the design of the genera 
icons is support for the graphical representation of generic 
calling sequence segments. In structured modeling, all genus 
types (except primitive entities) have a calling sequence. 
Therefore, the icons include an arrow that points to the 
geometric shape (the primitive entity icons omit the arrow). 
The calling sequence arcs are drawn from the top of the 
geometric shape of the called element to the tail of the 
arrow of the calling element. The icons for the various 
genus types are shown in Figure 3.3. 

5. Drawing Generic Graphs 

With the workspace and graphical representation of 
model elements defined, the next step is to define an 
algorithm for the positioning of model elements in a genus 
meli. The basis for this algorithm is that a genus graph 
can be divided into layers or levels. On the base level are 


all the genera that have no calling sequences or the 
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Figure 3.3 Graphical User Interface Genus Icons 
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primitive entities. The second level consists of the genera 
mene primi eive entities. The third level genera 
call second level elements and so on. The y-coordinate for 
an icon position is based on the level of the corresponding 
genus. 

It is possible for a genus to call subordinate genera 


2 If this gecurs, a placehölder is 


from two different levels. 
included on a level. This is to allow a calling sequence arc 
to be drawn across a level without interfering with the genus 
icons. The placeholder is the same size as the genera icons. 
Graphically it is a single vertical line that allows arcs to 

Span levels. 

The localization of related model elements is 
necessary to enhance the aesthetic quality of the graphical 
representation. Localization of model elements is the 
process of grouping directly related genera in the same area 
of the workspace. This is desirable so that the arc length 
and arc intersection are kept at a minimum. Arcs that are 
arawn the length of the screen are functionally correct, but 
greatly degrade user comprehension of the model. 

The positioning algorithm requires that the model 
elements be manipulated based on name, generic type, and the 
sl that they occupy. Therefore, institution of an 
internal data structure was necessary to support management 

SThis situation can occur in several instances. For 


example, a test element that calls an attribute and a 
peumvtive entity like T:DEMAND in the transportation model. 
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of elements for an entire model. The positioning inion me RE 
for an entire model is represented through an array of 
records. The position of individual model elements is 
depicted in a record. Each record contains a tieldzror ze 
following entities: the element name, the element type, the 
level, the icon’s x-coordinate, and the icon’s y-coordinate. 
Henceforth, this array will be referred to as the position 
array. The model element names and types are extracted from 
the database using the following SQL command: 

— SELECT ENAME, ETYPE Erom ENTES 

Additionally, the positioning algorithm needs 

information concerning the cross-referencing between the 
genera. Again, an array of records was selected as the 
appropriate internal data structure. Each record in this 
array represents a separate generic relationship. There 
exists a record for each arc in the generic graph. The 
records contain fields for the calling element name, calling 
element type, called element name, and called element type. 
This array is called the relation array. The SQL command to 
recall this informations 

- SELECT E1NAME, EILTYPE, (E2NAME, E 2 TYPE TONG 2056 ENN 

Once the relative position of the genera are estab- 

lished, the r-coordinates are assigned so that the model is 
centered in the workspace. Appendix A contains the mini- 
specification for the complete genus graph positioning 


al go Ea lame 
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EE EE EE EE is drawing 


the arcs between the genera. The algorithm bases the drawing 
of lines on the relationships between the genera. There are 
no references to the length or endpoints of a line. The 


Fer erenmerererences the position of an iCon to determine the 
endpoints of a line. As both the positioning of elements and 
line drawing are based on algorithms, the genus graph 
representation is totally independent of its mode of crea- 
tion. This allows a user to create a genus graph by direct 
entry of model information into the database. However, if 
the model was created graphically, the algorithm should 
provide a representation that closely resembles the original 
genus graph. 

The drawing of lines is accomplished by stepping 
through the relation array one record at a time. The calling 
element and Called element are determined. A search is then 
made of the position array to determine the x- and y-coor- 
dinates of the respective icons. A line is drawn between the 
two icons with the line's endpoints being a function of the 
lcon's x- and y-coordinates. A line that passes through a 
level of model elements must avoid the icons on that level. 
This is accomplished by drawing the line in two segments. 

The first line segment is drawn from the called element to a 
placeholder. The second segment is drawn from the place- 


holder to the calling element. 
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6. Drawing Modular Structures 


The purpose of this routine is to represent the 
modular structure exactly as shown in Figure 2.4. The 
modular structure is in actuality a simple tree Structures 
As such, the number of terminal nodes (or genera) represents 
themstructures width: Therefore, the width of a modular 
structure is determined by counting the number of genera. 
This information is used to center the modular structure 
vertically within the workspace. 

Physical reconstruction of the modular strucrus. 
begins by placing the root module at the vertical center of 
the workspace. The model elements contained directly within 
this root module are positioned in a second column. Each 
column represents a level of nienn an in the module stri 
ture. The positioning of these second column model elements 
is based on the eventual vertical position of the terminal 
genera. The entire structure is built in this manner, level 
by level. 

The requirement for monotone ordering of a modular 
structure mandates that a genus within a module make no 
forward references to other genera within the module. This 
means that there is a definite order to the vertical position 
of the genera. The relative position of the genera is 
included in the database representation of the RELSHIP 
relation. This information is referenced prior to phy oE 


positioning the genera of a module with the SQL command: 
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E OH UEPSNAME, ENDYPE, SE2NAME,CE2TYPE, REL POS from 
CONTAINZ;. 


7. Displaying Model Element Paragraphs 
The final system capability implemented as part of 
this thesis is module and genus paragraph viewing. When this 
function is selected by the user, a graphics cursor is 
enabled. The user moves the cursor about the genus graph or 
modular structure using the cursor control keys. The cursor 
is positioned over the desired model element and the RETURN 
key depressed to display the corresponding paragraph. 
A database query is made to access the paragraph 
o rmation as rt is not stored internal to the program. The 
SOL command for acquiring the paragraph information is: 
ENSEDECITCIDA,IDA STMI,GRANGE,GRULE,COMMENTS from ENTITY 
where ENAME - '«selected model element name»' and 
ETYPE = "<selected model element type>’;. 
Some of the retrieved fields will be NULL depending on the 
model element type. The paragraph data is then formatted and 
displayed within a window placed over the workspace. When 
the user completes viewing the paragraph, the ESCAPE key is 
depressed. This restores the image beneath the window and 


MMS cursor control to the user. 


D CONCLUSION 

Generalized requirements of a graphical user interface 
for a model management system were presented in this chapter. 
Also discussed were the design considerations for the system. 


It should be noted that much of the design work was completed 
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as the interface was being implemented. The prototyping 
development strategy provides the flexibility for easy 
modification of requirements during design and implementa- 


tion.: 
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TVs ES EOTYERZEVALUATION 


A. UNTROBUETION 

The design and implementation of the prototype graphical 
user interface for a model management system was discussed in 
Chapter III. In this chapter, the evaluation of that 
prototype is discussed. The areas of evaluation are suita- 
bility of the programming environment, adequacy of the 
initial requirements specifications and compatibility with 
other research efforts. The evaluation results include 
refined system requirements and a recommended disposition of 
the prototype. 
B., SUITABILITY OF PROGRAMMING ENVIRONMENT 

Originally there was some hesitancy in the selection of 
the programming environment described in Chapter I. First, 
the graphics facilities of the IBM PC were thought to be 
inadequate for an effective implementation of the graphical 
user interface. Attainment of acceptable response times was 
MESO a major concern in using the IBM PC. Secondly, the 
author had no experience using either the C programming 
language or the ORACLE database management system. Finally, 
the Halo graphics package, while highly touted commercially, 
was an unknown commodity. Despite these initial concerns, 
the prototype implementation uncovered no programming 


wa ronment deficiencies. 
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The stipulated hardware configuration and the Halo 
graphics package far exceeds original expectations. The 
requirement for the enhanced graphics adapter (EGA) proved a 
wise decision. It allows presentation of an aesthetically 
pleasing display with a complete IBM PC color palette and 
normally sized text characters. The hardware response time 
is also more than adequate. A genus graph filling the entire 
on-screen workspace, is cleared and redrawn in less than a 
second. 

The Halo graphics package provides two-dimensional 
graphics functions similar in capability to more specializes 
graphics systems such as the Silicon Graphics' IRIS-2400F 
station. The more advanced Halo functions used in the 
interface program include world coordinate system definition, 
viewport definition, polygon filling, and rubberband boxes“. 
The Halo version used was fully compatible with the Lattice-C 
compiler and supported numerous graphics drivers. 

The Lattice-C compiler provides the programming flexi- 
bility that the system requires. At one end of the spectrum, 
it permits integration with the ORACLE DBMS and the Halo 
graphics package. At the other end, direct calls to them E 


DOS BIOS interrupts are allowed. The only Criticism c: 


4The rubberband box function, when called init aa 
draws a box at a specified location. Subsequent calls will 
cause the first box to be erased and a new box to be drawn at 
whatever position is specified. A rubberband box was used as 
the graphics cursor in selecting model elements for 
displaying paragraphs. 


46 


mec Oomer ler tS that a source level debugger is not 
included as part of the basic software package. 

Pare Of che complete PC ORACLE DBMS software package are 
library modules which are linkable with Lattice-C produced 
modules. These modules allow use of ORACLE and SQL (Standard 
Query Language) commands from within the C source code. Once 
the system is compiled and linked, execution relies on the 
ORACLE system being embedded within the IBM PC’s extended 
memory. 

The overall performance of the graphical user interface 
in this programming environment is deemed sufficient. 
However, consideration should be given to implementations 
utilizing other hardware and software configurations. 

The ultimate goal for the complete MMS is integration 
mein a corporate information system. With this in mind, a 
mainframe version of the interface is highly desirable. This 
provides two options for hardware implementation. The first 
is using the mainframe’s remote terminals for displaying and 
manipulating the interface. The second is using micro- 
computers as front-end processors for the mainframe MMS. 

The development of the interface could be greatly 
wee l erated if an existing software product could be adapted 
to meet the system requirements. Apple's HyperCard provides 
a graphical database environment that might be well suited 


REP DUS application. A factor in the decision to build 
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either a new or a "turn-key" system is whether eii tHE S 


integrated with other parts of the MMS. 


ES REQUIREMENTS ENHANCEMENTS 

The final step in the prototyping design Strateq ae 
evaluating the system for both satisfaction of user require- 
ments and recommendations for further implementation. This 
section is an analysis of the prototype's weaknesses and 
deficiencies in the area of user requirements.  Refinements 
to the system design are suggested to rectify the prototype 
imperfections. The main purpose of the prototype was to 
prove the feasibility of re-creating adequate structured 
modeling representations from a database representation. As 
such, little attention was given to how the user communicates 
with the system. Several of the interface functions can be 
made more "user friendly" by improving the human-computer 
interaction., 

Currently, selection of system features use the function 
keys (Fl, F2, F3, etc.). However, this method of selec 
is not in keeping with the spirit of a completely modern and 
graphical interface. Research shows that the preferred 
picking mechanism is a mouse [Ref. 9: p. 108]. mre mi = 


would use the mouse to select from various pull-down menu 


options. The desired function is then selected] a. 
pull-down menu. The incorporation of the mouse requires no 
major control structure modifications. New software is 
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unnecessary as mouse functions are fully supported by the 
Halo graphics package. 

A mouse could also enhance the selection of model 
elements when displaying genus and modular paragraph informa- 
tion. The mouse cursor is placed on a model element’s icon 
and selection made by depressing the mouse button. The 
system then reads the mouse coordinates and searches the 
array containing icon positions to determine the model 
element selected. This information is then used to make the 
appropriate database query. 

Another weakness of the system concerns the drawing of 
arcs representing relations between model elements. The 


> of the generic 


current procedure allows arcs to span levels 
structure, providing a functionally correct representation. 
However, the aesthetic quality of the display is greatly 
diminished using this procedure. A better procedure for 
drawing arcs would certainly enhance the quality and under- 
standability of the generic representation. This procedure 
needs to eliminate the line disjointedness created by the 
placeholder icon used in the present procedure. 

The single screen workspace provided in the prototype was 
found to be too small for the representation of many models. 


One option is to use smaller icons for the model elements. 


unesd fficulty of this solution is that the text cannot be 


an complete discussion on the level structure of genus 
graphs is given in Chapter three. 
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scaled in proportion to the icons and in effect places a 
lower limit on the size of the icons. The second, and more 
feasible, option is a virtual workspace. The user can üse 
the arrow keys to scroll left, right, up, or down throuchewe 
the model representation. In addition, the system should 
provide the capability of proceeding directly to a model 
element specified by name. 

The improvements discussed will greatly increase the user 
friendliness and overall quality of the prototype. At this 
point, however, a decision must be made to continue improving 
the prototype or use the prototype as the input to the design 
phase of the traditional life-cycle (TLC). Recommendations 


concerning this decision will now be presented. 


D. DISPOSITION lee 

Transformation of a prototype system into a production 
system is currently a highly debated topic. Advocates of the 
prototyping methodology contend that the TLC process is 
unnecessarily long and that prototyping is the solution to 
timely software production [Ref. 6: p. 252]. Defenders 
the TLC approach view prototypes as 'toy' systems that aid in 
fine tuning the overall system design (Ref. 4: p. 226], 
(Rer, 10: p. 3]. The characteristics of theip oO COREE 
graphical user interface support the latter opinion. 

The impetus behind the development of the graphical user 
interface prototype was to produce a working portion of the 


complete system. Therefore, several features considered 
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essential in a production system were omitted. Among these 
features are extensive error-checking mechanisms, source code 
optimization, and well documented trails of design and 
implementation decisions [Ref. 4: p. 226]. 

Testing the prototype focused on the correctness of the 
various interface displays rather than the identification of 
program defects. Therefore, numerous minor bugs remain 
uncorrected. Optimization of source code was limited to 
generation of commonly used modules. The only available 
documentation for the system is comments within the source 
code and this thesis. There is no method to trace the 
development strategy in converting the design into source 
code. The institution of programming standards is not easily 
accomplished during the maintenance phase. Thus, using the 
prototype as the basis for proceeding on to the TLC design 
phase will provide the potential to make improvements in 
these essential areas. 

A second factor prompting the decision to forego the 
prototype is the need to integrate this portion of the 
graphical user interface with other research efforts. As 
stated in Chapter III, the model creation and editing 
functions were designed and implemented concurrent with this 
thesis. Integration of the two prototypes will require the 
resolution of the following design issues: 


- Determination of data structures satisfying the needs of 
model building and re-creation functions. 
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- Development of a screen design supporting all the various 
functions of the complete system. 


- Design of a control structure to support the entire 
graphical user interface. 


- Model element icons standardized on the basis of size, 
shape, color, and labeling. 


- Standardization of the model element paragraph displays 
to facilitate entry, modification, and viewing. 


- A method of re-creating a model representation that 
exactly resembles the representation as it was originally 
created. 

Resolving the differences in representation of the model as 
created and re-created is the most difficult design issue. 
The current model creation program allows the user to place 
icons and draw relational arcs arbitrarily while the re- 
creation program draws the icons and arcs algorithmically. 
This results in considerable disparities between the created 
(Figure 4,1) and re-created (Figure 4.2) representations. 
There are two possible solutions to this problem. The first 
is to expand the database to include a relation for storing 
graphical coordinates for the icons and arcs. The second 
solution is to reformat the user’s representation into the 
algorithmic representation each time the user represents a 
relation between the icons. The advantage of the first 
solution is that the user obtains a representation exactly as 
drawn. The disadvantage is the need for additional database 
storage space. The second is a trade-off in that the user’s 
exact model representation is forfeited in favor of saving 


storage space. The decision as to which method is better, 
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Figure 4.1 Graphical User Interface Genus Graph: 
Created Version 
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Figure 4.2 Graphical User Interface Genus Graph: 
Re-created Version 


24 


can best be made through a complete life-cycle analysis of 
the problem. 

To reiterate, design issues are extremely difficult to 
correct in a maintenance environment. Integration of the two 
systems is mainly a maintenance effort. In addition, the 
final system must include several functions not prototyped. 
These factors strongly support the decision of beginning the 
design of the system anew using the traditional life cycle. 

In conclusion, the prototype, while not acceptable as a 
production system, allowed highly productive system analysis. 
User requirements were solidified and a basis for the design 
phase of the production system was provided. Traditional 
life-cycle development is, therefore, greatly enhanced 


through the use of a prototype. 
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V. CONCBEUSESM 


A. DISCUSSION 

This thesis was conducted to prove the feasibility of 
implementing a graphical user interface for a model manage- 
ment system (MMS). Research in this area is necessary in 
overcoming the major obstacles confronting the management 
science and operations research (MS/OR) disciplines. The low 
productivity of MS/OR personnel and the low level of model 
acceptance by management are the two largest factors hinder- 
ing the growth of modeling technologies. An MMS that is easy 
to use and understand will greatly aid in overcoming these 
difrseulteies, 

A new type of MMS must possess several features to gain 
acceptance by both management and MS/OR practitioners. It 
should use a single model representation for all levels of 
analysis. The representation must be general enough to 
support numerous types of models. The system must also 
support the entire modeling life-cycle, allow implementation 
on a micro-computer, support integration with a database 
management system (DBMS), and provide fast, accurate results. 
Structured modeling is a framework for construction of suem 
syst: 

A significant part of this MMS will be the user inter- 


face. Structured modeling relies on pictorial 


Ger 


representations of models suggesting the use of a graphical 
interface. This thesis delineates an initial set of require- 
ments specifications for the graphical user interface. The 
completeness of the specifications could not be verified thus 
warranting the use of a prototype development strategy. The 
portion of the interface undertaken in this thesis concerns 
the re-creation of graphical model representations from a 
database representation of the model. 

Prototyping allowed rapid design and implementation of 
this part of the graphical user interface. The system used 
an IBM PC with an embedded ORACLE DBMS. It proved the 
feasibility of implementing a modern user interface for a 
structured modeling based MMS. The prototype was also 
evaluated to determine the completeness of the user specifi- 
cations and the disposition of the prototype. The evaluation 
of the prototype revealed several useful functions overlooked 
in the initial specification of requirements. However, it 
was recommended that the prototype not be enlarged to 
incorporate these improvements. Instead, the prototype and 
recommended enhancements should be the basis of design for 
conducting a complete life-cycle implementation of the 


complete user interface. 


PH RECOMMENDATIONS FOR FUTURE STUDY 
Two research opportunities in the area of computer-based 
model management systems surfaced as a result of this thesis. 


The first concerns consolidation with concurrent research 
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efforts. The need exists to integrate the refined require- 
ments specifications from the varıous efforts into a single 
and complete interface. 

A second area of interest is the commercial viability of 
the entire MMS. Since users interact with a system through 
its interface, the graphical user interface is an excellent 
tool for evaluation in this area. Model practitioners and 
management can use the interface to provide inputs concerning 
the demand for such a product. 

Research in the area of model management should focus on 
increasing the organizational acceptance of MS/OR models. 

The complexity of many decision making processes is greatly 
reduced through the use of models. Therefore, a model 
management system should be an integral part of an organiza- 
tion’s information system. Neither the modeling ideology 
used, the user interface employed, nor the system implementa- 
tion environment should inhibit the attainment of the actual 


goal of increased model usage. 
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APPENDIX A 


SELECTEDSMTNIZSERETFICATIONS 


1 GENUS GRAPH POSITIONING ALGORITHM 
1.1 Initialize the level counter to 1. 
1.2 For each record in the relation array: 


1.2.1 Determine if the called element is a primitive 
entity. 


1.2.1.1 If so, enter the called element name, 
called element type, and value of the 
level counter into the next available 
record in the position array and then 
proceed tojstep ms 2. 


IN ^. If not, proceed to step 1.2.2. 


Matos. back to step 1.2.1 until all relation 
array records have been checked. 


1.3 Increment the level counter by 1. 


1.4 Eliminate all duplicate records in the position 
QI. 


1.5 For each record in the relation array: 


1.5.1 Determine if the calling element calls an 
element on the level below the current level 
counter value. 


1.5.1.1 If so, enter the calling element 
name, calling element type, and value 
of the level counter into the next 
available record in the position 
array and then proceed to step 1.5.2. 


ISP Er f not, proeeedrtesstep 1.522: 


Moo» back to step 1.5.1 until all relation 
array records have been checked. 
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Ls 


E 


6 


> 


5 


For each record in the position array with a 
a level value equal to the current level 
counter value: 


1.5.3.1 Determine if the calling element 
calls another element on the same 
level, 


1.5.3.1.1 If so, replace all 
occurrences of the element 
with placeholders and 
proceed to step 1.5.3.2. 


1.5.3.1.2 If not, proceed tos 
1.0525 


1.5.3.2 Loop back to step 1.5.3.1 until m 
position array records have been 
checked. 

Eliminate duplicate records in the current 

level. 

Increment the level counter by 1l. 

Loop back to step 1.5.1 until all calling 


elements in the relation array have been 
transferred to the position array. 


Determine the level with the most elements. 


qe 


Ge 


1 


Use the value from step 1.6 to center the 


graph horizontally and calculate the 
x-coordinates. 


Determine how many levels in the graph. 


1% 


En: 


d 


Use the value from step 1.7 to center the 


graph vertically and calculate the 
y-coordinates. 
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2 GENUS GRAPH LINE DRAWING ALGORITHM 


ZW For each record in the relation array: 


2 


SL: 


Le: 


ln 


SIS 


a. 


I 


Determine the calling element name, calling 
element type, called element name, called 
element type and the level value for each 
element. 


Get x- and y-coordinates for the elements 
from the position array. 


fe ene dustrtoreuecowbetweemmbthe level values 
equals 1: 


2.1.3.1 Calculate the starting and ending 
points for the line. 


2.1.3.2 Draw the line. 


If the difference between the level values 
is greater than 1: 


2.1.4.1 For each level crossed: 


2.1.4.1.1 Search the position array 
for the placeholder icon 


that represents the level 
crossing for that relation 
and calculate line 


starting and ending 
points. 


2.1.4.1.2 Draw the line. 

2.1.4.2 Calculate the starting and ending 
points for the line from the last 
placeholder icon to the calling 
element icon. 


Bere Draw the line. 


Wop Dack to step 2.1.1 until allzrecordszhaye 
been checked. 
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APPENDIX B 


GRAPHICAL USER INTERFACE SON TERT ODE 


NV k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K 


* (HEADER FILE: GENUSTH 

WRITTEN BY: MARVIN A. WYANT, 
DATE OF LAST MODIFICATION: 11 MARCH 1988 
PURPOSE : 


J RE 


* 
* 
* 
* 
* 
* 


TO GLOBAL CONSTANTS AND GLOBAL DATA 
STRUCTURES. 


/* DEFINE GLOBAL CONSTANTS FOR THE COLORS */ 


det ime 
tdefine 
tdefine 
#define 
#de fine 
#define 
define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#de fine 
#define 


BLACK 0 
BLUE 1 
GREEN 2 
CYAN 3 

RED 4 
MAGENTA 5 
BROWN 6 

LT GRAY 7 
DARK GRAY 8 
LT BLUE 9 
LT GREEN 10 
TC NNN 
LT RED 12 
LT MAGENTA 13 
YELLOW 14 
WHITE 15 
NOTHING -1 


/* DEFINE GLOBAL CONSTANTS FOR THE FUNCTION KEYS 


tdefine 
#define 
oleme 
#define 
#define 
define 
#define 
#define 
#define 
#define 
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k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k x x K 


eo 


x 
x 
x 
THE PURPOSE OF GENUS.H IS TO ASSIGN VALUES * 
* 
x 
* 


/ 


#define 
#define 
#define 
#define 
tdefine 
tdefine 
tdefine 
#define 
#define 
define 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


#define 
#define 
#define 
#define 
#define 
define 
#define 
#define 
#define 
“define 


/ * 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


#define 
#define 
#define 
#define 
#define 
#define 


DEFINE GLOBAL CONSTANTS FOR THE CURSOR KEYS 


SHIFT Fl 
SHIET EZ 
SHIFT F3 
SHIFT F4 
SHIFT F5 
SHIFT F6 
SHIFT F7 
SHIFT F8 
SHIFT F9 
SHIFTF10 


CRETEI 
CTRL F2 
CTRL F3 
CTRL F4 
CTRL F5 
CTRL F6 
CERERE? 
CTRL F8 
CTRL F9 
CORE IO LOS 


104 
BOS 
106 
107 
108 
10 9 
110 


ALT Fl 
ALT_F2 
ALT_F3 
ALT F4 
ALT FS 
ALT_F6 
ALT_F7 
EST 

ALT F9 112 

ALT F10 113 


E 


HOME 71 

UP ARROW 72 

PG UP 73 

LEFT ARROW 75 
RIGHT ARROW 77 
END 79 

DOWN ARROW 80 
PG DN 81 


CTRL HOME 119 
CEREIPG UP 132 

CTRL LEFT ARROW 115 
CTRL RIGHT ARROW 116 
CTRL END 117 

CTRL PGDN 118 
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#define INS 82 
#define DEL 83 
define ESCW27 


/* A GLOBAL ARRAY FOR STORING THE SCREEN WHEN USING A 


WINDOW */ 


int window array[30000]; 


/* TYPE DEFINITION FOR THE DATA STRUCTURE TOCREPRESEDM 


RELATIONS BETWEEN 


typedef struct { char 
char 
char 
char 


MODEL ELEMENTS */ 


elname[9]; 
elc ype iE 
e2name[9]; 
e2type[3]; 


M E pes, 
SEE Ese, 


/* TYPE DEFINITION FOR THE DATA STRUCTURE TO REPRESENT THE 
POSITION OF A MODEL ELEMENT */ 


typedef’struce (cher 


name [9]; 


char type [3]; 
float xpos; 
float ypos; 
int level; 

PE OK 


/ K k k k k k k k k k k k k k k k k K k k k k k k k k k k k k k k k Kk k k k k k k ke x x e ee kk ke ek kk kk 


END GENUS.H 


K K k k k k k k k k k k k k k k k k k x k k k k k k k k k k k k k k k k Xk k k k k k k k k k k k £ k k k k k k Kk K / 
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f Kk kk oko ok ke Kok ke koe kk ke kk kk he ke koh ke ke ke x k x k k k k k k k k k k x % k ke ke kk k k k ke ke kk kk 


* PROGRAM FILE: MAIN.C 


X WRITTEN BY: MARVIN A. WYANT, JR. 

~*~ DATE OF LAST MODIFICATION: 11 MARCH 1988 

PURPOSE: CONTAINS THE MAIN CONTROL STRUCTURE FOR THE 

* MODEL MANAGEMENT SYSTEM GRAPHICAL USER 

* INTERFACE. THIS MODULE ALSO ALLOTS SPACE 

* FOR THE ARRAY OF DATA STRUCTURES. 

*Hk kk k k k k k k k k k k k k k k k k k k k x k k k k k k k k k k k k k k k k k k k k k k k k k x k k k k k x x 


Mc lude "stdio.h" 
mmnelude "string.h" 
mmelude "stdlib.h" 
finclude "genus.h" 


Mnelude "utils.h" 
include "icons.h" 
raěnelude "initdisp.h" 


include "help.h" 
finclude "drawgen.h" 


/* 
X 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
Ié 


A STANDARD LATTICE-C HEADER FILE 
POST ANDARDZELEATTICE-CY*HEADER ETLE 
A STANDARD LATTICE-C HEADER FILE 
DEFINES PREPROCESSOR VARIABLES, 
TYPES, AND DATA STRUCTURES 
ADDITIONARM C UTILITIES NOT 
TNCEUDEDZIENGEATTICEZG 

FUNCTIONS THAT DRAW THE VARIOUS 
ELEMENT ICONS 

INITIALIZES THE GRAPHICS SYSTEM 
AND DRAWS THE SYSTEM SCREE 
PRESENTS THE HELP SCREENS 
CREATES A GENUS STRUCTURE FROM 
THE ELATIONS DESCRIBED BETWEEN 
THE MODEL ELEMENTS 


/* THE MAIN CONTROL STRUCTURE */ 


main() 


{ 


/* HOLDS THE VALUE OF THE KEY INPUT BY THE USER */ 


int key; 


/* ALLOTS SPACE FOR THE DATA STRUCTURES */ 


BERSHP *relptr; 
BOSTT2*posptr; 
POSIT *temptr; 


relptr 
posptr 
temptr 


(PROSIT =) 
(POSIT *) 


(RELSHE ~) 


calloc (100, sizeof (RELSHP)); 


calToc (5007357 2eorftEosIT)); 
callocx500, sizeof (POSIT)); 


/* INITIALIZE THE GRAPHICS SYSTEM AND THE SYSTEM 


SCREEN */ 
miiedisplay (); 


65 


* 
* 
* 
* 
* 
* 
* 
* 


A: 
7 
a 
= 
SE 
En 
be. 
64 
i 
= 
7 
E 
n 
= 
27 


while 


{ 


(1) 


/* GET THE USER'S INPUT */ 


key = getkey(); 
Switch ( key ) 
/* DISPLAY HELP SCREENS */ 
case Fl: help({); 
break; 
/* RE-CREATE A GENUS STRUCTURE */ 
case F2: draw genus (relptr,pƏsptr r mnm 
break; 
/* SPARE INPUT KEYS */ 
case po break: 
case F4: break; 
case F5: break; 
case F6: break; 
case F7: break; 
case F8: break; 
case F9: break; 
/* RETURN TO DOS */ 
case F10: break; 


/* SPARE INPUT KEYS */ 


case 
case 
case 
case 
case 
case 
case 
Case 
Case 
Case 


Case 
Case 
Case 
Case 
case 
case 
Case 
Case 
Case 
Case 


CENIE- 
CE 
CTRL F3: 
CTRL F4: 
CTRIGES: 
CTRL F6: 
CTRL F7: 
CTRL F8: 
CTRL F9: 


EE 


Se 
SEE ED 
SHE E 
SHIFT F4: 
SHIET F5: 
SHIFT F6: 
SHIFT F7: 
SHIFT F8: 
SHIFT F9: 
SHIFTF10: 


break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 


break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 
break; 
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case ALT Fl: break; 
case ALT F2: break; 
case ALT F3; break; 
Case ALT F4: break; 
case ALT F5: break; 
case ALT Fomwbreak; 
EE 
case ALT F8: break; 
Kase BDI FP9: break; 
case DLE: break; 


/* SCREEN MOVEMENT KEYS */ 


case 
Case 
Case 
Case 
case 
case 
Case 
ease 


Case 
Case 
Case 
Case 
Case 
Case 


Case 
Case 


HOME: Dbreak; 

UP ARROW: break; 

FG UP break; 

LEFT ARROW: break; 
RIGHT ARROW: break; 
END: break; 

DOWN ARROW: break; 
PG DN: break; 


CTRL HOME: break; 

CTRL PG UP: break; 

CTRL LEFT ARROW: break; 
CTRL RIGHT ARROW: break; 
CTRL END: break; 
CTRLIFGDN: break; 


INS: break; 
DEL: break; 


default: break; 


) 


/* RETURN TO DOS */ 
if ( key F10 ) 
break; 


) 


/* CLOSE THE GRAPHICS SYSTEM */ 
closegraphics(); 


) /* END MAIN */ 


/ K k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k x x k k k k k k k k Xx k x x 


END MAIN.C 


K k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k xk k k k x x / 
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[kkk k k k k k k k k k k k k k k k k k k k k k k k k x k k x k k k k k k k k k x k k k k k k k k k k k k k k k x x 


* HEADER EFEFTIE&EE R TT TS H * 
x WRITTEN BY: T MARVIN A. WANTER £ 
x DATE OF LAST MODIFICATION: FMC- * 
* PURPOSE: A LIBRARY OF STANDARD UTILITIES NOT INCLUDE ERM 
= IN THE LATTICE-C PACKAGE ^" 
X X 


Kk k k k k k k k Kk k K k Kk kx ko A X ko kok ook ko ko k k k x k xk xk xk xk x Xx x X K K X KAHA K X Xx X Ak XA 


/ 
#include "dos.h" /* A STANDARD LATTICE-C HEADER FILE */ 

/* CLEARS THE SCREEN WHEN NOT IN THE GRAPHICS MODE */ 

cU poco 


{ 
union REGS reg; 


reg. e E < VE 

Eet Dt Ee 

EE EE TE 

Feet ae 


int86( Oxl0, Ffereg creo: 


gotoxy( 0,2027 
} /* END CLRSCR */ 


/* POSITIONS THE SYSTEM’S TEXT CURSOR AT AN X,Y COORDINATE 
ON THE SCREEN */ 


Gol ov (eo owe) 
EE ron. 
{ 


Una On REGS Treg; 


reg hani r2; 
req,ts;b5bho- 0; 
reg.x.dx e ( row << 8m i reol 


intS8o( Oxl0, £reg, regm): 
} /* END GOTOXY */ 
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/* GETS THE VALUES OF THE FUNCTION AND CURSOR KEYS */ 


int getkey () 
{ 


int keyl; 

int key2; 

do Í 
keyl = getch(); 
if ( keyl == 0) 


{ 
key2 = getch(); 
return ( key2 ); 


} 
} while ( keyl != 0 ); 
) /* END GETKEY */ 


f Kk Ck kk ck kk kk £ % K ke ke Kk Kk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K x 


END C UTILS TH 


Kkk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k x x / 
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[kkk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K 


x 


x 
x 
* 
* 
* 
* 
* 
* 


HEADER FILE: 


PURPOSE: 


PLACEHOLDER ICON. 


THE X- AND 


ICONS.H 

WRITTEN BY: MARVIN A. WYANT, 
DATE OF LAST MODIFICATION: 
CONTAINS A LIBRARY OF FUNCTIONS USED TO DRAW 


JR: 
ll MARCH ee 


EACH FUNCTION T REQUIRES 
Y-COORDINATES AND THE MODEL 


ELEMENT NAME. 


K Kk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K k k K k k k k k k k k k k xk k k k X x 


* 
* 
* 
* 
THE VARIOUS MODEL ELEMENT ICONS AND THE k 
* 
* 
* 
* 


/ 


/* DRAWS THE PRIMITIVE ENTITY CON 


draw pe( x, 


Y, 
r loat x. w; 


char node name [9]; 
{ 

mt color 

int foreground 
int background; 
float x57 9 M E 
char labels 


xl = x; 

ip c ee 

Vi c= a SG 

Vie t 15108 (0 

/* SET THE COLOR OF 
color = GREEN; 
setcolor(z8eolor |: 


/* DRAW THE ICON */ 
bari «d! sex. 


/* SET ICON OUTLINE 
color = BLACK; 
sSsetcolor( &color j: 


/* OUTLINE THE ICON 
pou EL E YA 


xÏ 
y E 
/* 
foreground - 
background - 


x1 4S 10.20; 
ALI SO 


BLACK; 
GREEN; 


node name ) 
/* BOTTOM-RIGHT COORDINATE OF THE ICON */ 


/* NAME OF THE MODEL ELEMENT */ 


THE ICON */ 


SPD 


COLOR */ 


x / 
&y2 ); 


SET THE TEXT COLOR FOR WRITING WITHIN THE ICON */ 
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/* LABEL THE ICON */ 
settextclr( &foreground, &background ); 
mevtcurabs( &xl, «yl ); 


sepepviemebel; "PE" ); 
text( label ); 


pax 30.0; 
pa yi — 13.0; 
Mevecurabs( &xl, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 
NAME */ 

background - WHITE; 

settextclr( &foreground, &background ); 


/* WRITE THE NAME OF THE ICON */ 
beum node name ); 


delteur(); 
} /* END DRAW_PE */ 





p 


/* DRAWS THE COMPLEX ENTITY ICON */ 


draw ce( x, y, node name ) 


{ 


float x, ys; /* BOTTOM-RIGHT COORDINATEZORZTHE STONE, 
char node name[9]; /* NAME OF THE MODEL ELEMENT */ 


nt. colo 

int foreground, 

Ime background, 

int arrowsides = 3; 
int shapesides = 4; 
float” xl, Viana, 


/* RELATIVE X,Y COORDINATES FOR DRAWING THE ARROWHEAD */ 


static float xarrow[] = { -4.0, 8.0, -4.0 }; 
static float yarrow[] = { =82 070307 E 
/* RELATIVE X,Y COORDINATES FOR DRAWING THE ICON */ 
static float xshape[] = { -17.0, 17 0 I7 77 “IN 
static float yshape[] = { 17.0, 17.0, 1: 0 m RE 


char label] IT: 
x v= M 
vie = 77 86101 
movabs( &xl, &yl ); 


/* SET THE COLOR OF THE ICON 37 
color = GREEN; 


/* DRAW THE ICON */ 

polyfrel( xshape, yshape, &shapesides, &color ); 
/ 2 SET ICON OUTIINE C Ol Opa 

Color = BLACK; 

seteoloer iecolor rE 


/* OUTLINE THE ICON */ 
polylnrel( xshape, yshape, &shapesides ); 


/* DRAW THE ARROWHEAD LEADING INTO THE ICON */ 
dx UU 

dyr == 1606 

Lnrel( GEES 

movabs ( 6x1, &yl ); 


polyfrel( xarrow, yarrow, &arrowsides, &color ); 


xl = x1 - 7.0; 
yl v 0. 
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/* SET THE TEXT COLOR FOR WRITING WITHIN THE ICON */ 
foreground = BLACK; 

background = GREEN; 

settextclr( &foreground, &background ); 

movtcurabsí &xl, &yl ); 


/* LABEL THE ICON */ 
Sserepy\ label, "CE" ); 
text( label ); 


= jJ + 30,0; 
Al = 13.0; 
uevtourabsi( &xl, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 
NAME */ 

background - WHITE; 

settextclr( &foreground, &background ); 


/* WRITE THE MODEL ELEMENT NAME */ 
text( node name ); 


meltcur () ; 
} /* END DRAW CE */ 
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/* DRAW THE ATTRIBUTE ICON */ 


draw a( x, y, node name ) 

float x, y; /* BOTTOM-RIGHT COORDINATE OF THE ICON */ 
char node name[9]; /* NAME OF THE MODEL ELEMENT */ 

{ 

Inter color: 

int foreground; 

ine background - 

int arrowsides = 3; 

Mae aay. 


l RELATIVE X,Y COORDINATES FOR DRAWING THE ARROWHEAD */ 
Static float xarrow[] = { -2:0 S 0 s 
static float yarrow[] — ( 8.0 72120 E 


/* RADIUS FOR DRAWING THE ICON */ 
fioat radius: =- I9 0: 

char label[2]; 

ee 

v |= TS SOE 

movabs( &xl, &yl ); 


/* SET THE COLOR OF THE ICON */ 
Color = BLUE; 
set color (Color); 


/* DRAW THE ICON */ 
EG (m6rac usm | 


IA SET ICON OUTLINE COLOR: 
color = BLACK; 
setcolor( color. ); 


/* OUTLINE MAE ICON */ 
cr radius `): 


/* DRAW THE ARROWHEAD LEADING INTO THE ICON */ 
LS SO 

movabs( &xl, &yl ); 

dx = 0705 

dy = 45620: 

lnrel( &dx, &dy ); 

movabs( &xl, &yl ); 


polyfrel( xarrow, yarrow, &arrowsides, &color ); 


< 10 ee 
y 15890) 


» 
vl 
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/* SET THE TEXT COLOR FOR WRITING WITHIN THE ICON */ 
foreground = WHITE; 

background = BLUE; 

settextclr( &foreground, &background ); 

meoevecurabs( &xl, &yl ); 


/* LABEL THE ICON */ 
strcpy( label, "A" ); 
text( label ); 


a — 211 + 27.05; 
s 13.0; 
meyteurabsı &xl, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 
NAME */ 

foreground BLACK; 

background = WHITE; 

settextclr( &foreground, &background ); 


/* WRITE THE MODEL ELEMENT NAME */ 
Ecc Dede name ); 


deltcur(); 
} /* END DRAW A * / 
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/* DRAW THE VARIABLE ATTRIBUTE ICON */ 


draw val x, y node ame o) 

float x, y; /* BOTTOM-RIGHT COORDINATE OF THE nee a 
char node name[9]; /* NAME OF THE MODEL ELEMENT */ 

{ 

int color 

int foreground; 

Int backgreund; 

int arrowsides = 3; 

int shapesides = 6; 

float cc! y dv; 


/* RELATIVE COORDINATES FOR DRAWING THE ARROWHEAD */ 
static float xarrow[] = { -470/ 8.0, OTT e 
static float yarrow[] = { -8 0 OTO -m 


/* RELATIVE COORDINATES FOR DRAWING THE ICON */ 
Static float xshape[] = 
{ -6.0, -11.0, 17.0, 17.0, T1 0 NECEM 
Static float yshape[] = 
( 0.0, 20.0, 14.0, -147072070 E 
char label[3]; 
x1 = x +21 009: 
wl see 
movabs( &xl, &yl ); 
¡“TSED THE GCOCELOR OF THE. ECON <7 
color BLUES 
/* DRAW THE ICON */ 
polyfrel( xshape, yshape, &shapesides, “¿color ); 


/[* SET ICON OUTLINE COLOR */ 
color = BLACK; 
set color (coto: 


/* DRAW THE OUTLINE */ 
polylnrel( xshape, yshape, &shapesides ); 


/* DRAW THE ARROWHEAD LEADING INTO THE ICON */ 
ax = 007 

== 650 

Inrel( &dx, &dy ); 

movabs( &xl, &yl ); 


polyfrel( xarrow, yarrow, &arrowsides, &color ); 


ri ergi = 


14:50; 
y wd cto 
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/* SET THE TEXT COLOR FOR WRITING WITHIN THE ICON */ 
foreground = WHITE; 

background = BLUE; 

settextclr( &foreground, &background ); 
Nevreurabesws:l,#&yl ); 


/* LABEL THE ICON */ 
Ssereoy( label, "VA" ); 
text( label ); 


> = + 30.0; 
kli = yl — 8.0; 
meutcecurabs( &xl, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 


NAME */ 
foreground = BLACK; 
background = WHITE; 


Settextclr( &toreground, &backgroungd ); 


/* WRITE THE MODEL ELEMENT NAME */ 
rezt (mode name ); 


aertceurt); 
} /* END DRAW VA * / 
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/* DRAW THE FUNCTION ICON */ 


draw f( x, y, node*name `) 

float x, y; /* BOTTOM-RIGHT COORDINATE OF ICON */ 
char node name[9]; /* MODEL ELEMENT NAME */ 

{ 

int color- 

int foreground, 

int background: 

int arrowsides = 3; 

int shapesides = 4; 

float sl, vi a, ay: 


/* RELATIVE X,Y COORDINATES FOR DRAWING THE ARROWHEAD */ 
static float xarrow[] = { -4.0, 8.073 = p. 
static float yarrow[] ( 58.0, 0.0, STONE 


/* RELATIVE X,Y COORDINATES FOR DRAWING THE ICON */ 
static float xshape[] = { -17.0, 17.0, 17 0 pK A 
static float yshape[] { 0.0, 34.0, 34560 p o SOD 
char labe 7 r 

x] = wn cp Ep mO 

vl = Vy ee ESET 

movabs( &xl, &yl ); 


Il 


/* SET THE COLOR OF THE ICON */ 
color = YELLOW: 


/* DRAW THE ICON */ 
polyfrel( xshape, yshape, &shapesides, &color ); 


/* SET ICON OUTLINE COLORA, 
color = BLACK; 
seccolor( <color ); 


/* OUTLINE THE ICON */ 
polylnrel( xshape, yshape, &shapesides ); 


/* DRAW THE ARROWHEAD LEADING INTO THE ICON */ 
dx = 0.0; 

ey 5.0 

lnrel( &dx, &dy ); 

movabs( &xl, &yl ); 


polyfrel( xarrow, yarrow, &arrowsides, &color ); 


xl 2172370: 
yl v1 3 907 
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/* SET THE TEXT COLOR FOR WRITING WITHIN THE ICON */ 
foreground = BLACK; 

background = YELLOW; 

settextclr( &foreground, &background ); 

Movecurabs( $X1, «yl ); 


PRES BEL THE ICON */ 
Eum label, "E" ); 
text ( label ); 


a= Z 1 + 27.0; 
i yl) — 8.0; 
mewbcurabs( &xl, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 
NAME */ 

background - WHITE; 

settextclr( &foreground, &background ); 


/* WRITE THE MODEL ELEMENT NAME */ 
text ( node name ); 


Sedem), 
M END DRAW F */ 
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/* DRAW THE TEST ICON% 


draw t( x, y, node name ) 
float x, y; /* BOTTOM-RIGHT COORDINATE OF THE ICON */ 
char node name[9]; /* NAME OF THE MODEL ELEMENT */ 
{ 
int colors 
int foreground, 
int background; 
int arrowsides = 3; 
int shapesides = 7; 
ek Ke ere 


/* RELATIVE X,Y COORDINATES FOR DRAWING THE ARROWHEAD */ 
static float xarrow[] = { -4.0, 8.0, -4.0 }; 
static float yarrow[] = I "FO 9000 ER 


/* RELATIVE X,Y COORDINATES FOR DRAWING THE ICON */ 
static float xshape[] = 

{ -7.0, -10.0, 10,0, 14.0, 10.0, = ON ON Pi 
Static float yshape[] = 

{ 0.0, 17.0, 17.0, 0.0, =£ 1 Or 1 s P DE 
char label[2]; 
x] = 7118710 
yl ="y9 + poo 
movabs( &xlomevl E 


/* SET THE COLOR OF THE ICON */ 
color = RED; 


/* DRAW THE ICON */ 
polyfrel( xshape, yshape, &shapesides, &color ); 


/* SET ICON OUTLINE COLOR */ 
color = BLACK; 
Set color (WeEcolor ): 


/* OUTLINE THE ICON */ 
polylnrel( xshape, yshape, &shapesides ); 


/* DRAW THE ARROWHEAD LEADING INTO THE ICON */ 
dx = 0.0; 

dvo 

Inrcel veds tdy 1) 

movabs( &xly, &yl ); 


polyfrel( xarrow, yarrow, &arrowsides, &color ); 


ll 
yl 


specu 
E 30 
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/* SET THE TEXT COLOR FOR WRITING WITHIN THE ICON x 
foreground = WHITE; 

background = RED; 

Seerrextelr( sforeground, &background ); 

mneoceurabsí( &xl, &yl y; 


pf Lae THE ICON */ 
Ser p label, "T" ); 
text( label ); 


xl = xl + 27.0; 
yl = yl - 13.0; 
movtcurabs ( 4x1, &yl ); 


/* SET THE TEXT COLOR FOR WRITING THE MODEL ELEMENT 


NAME */ 
foreground = BLACK; 
background = WHITE; 


Settextclr( &foreground, &background ); 


/* WRITE THE MODEL ELEMENT NAME */ 
Bet (node name ); 


deltcur(); 
} /* END DRAW T */ 


/* DRAW THE PLACEHOLDER ICON */ 


draw space( x, y ) 
float x, y; /* BOTTOM-RIGHT COORDINATE OF ICON */ 
{ 
lose xl, yl; 
ii color; 


/* SET COLOR FOR LINE THROUGH PLACEHOLDER ICON */ 
color = BLACK; 
setcolor( &color ); 


/* DRAW THE LINE */ 
xl = x + 17.0; 

A sy; 

movaos(msxl, svl ); 
er 50,0; 
maps ( exl, &yl ); 

) /* END DRAW SPACE */ 


/ K Kk K k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K K k k k K k k K k k K k k k k k k k k 


END ICONS: H 
Kk kkk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k Kx / 
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AA AX XX AAA AXA AAA AAA A AAA Á AAR AA AAA AAR A x x Mx Xx A kx X X X IK kx x x x x x KK KK KK X Xx xx 


HEADER ETEBESSEUBTIDISE.H A 
WRITTEN BY: MARVIN A. WYANT, JR. z 
DATE OF LAST MODIFICATION: 11 MARCH 1988 d 
PURPOSE: TO DETERMINE WHAT GRAPHICS DEVICE Is ^ 

INSTALLED AND INITIALIZE THE SYSTEMS eRe 5 
WI 


/* INITIALIZE THE SYSTEM SCREEN */ 


initdisplay () 


int mode; 

char device name[13]; 
ineseolor TE 

int roreground. 
int background: 
int border; 

ESSE: cl 

float. yi; 
tloaticcz- 

float y2; 

char message [25]; 


/* SELECT THE APPROPRIATE GRAPHICS DEVICE */ 
select device( device name, &mode ); 


/* INSTALL THE GRAPHICS DIVICE DRIVER */ 
setdev( device name ); 


/* INITIALIZE THE GRAPHICS SYSTEM ~ 
initgraphies( «¿mode 9; 


/* SET THE WORLD COORDINATE SYSTEM */ 
xl = 0,0; 1270.02 22527639.07 92 = Sear 
setworld(-&xl 211, 281 7 NE 


/* INITIALIZE THE SYSTEM "SCREENS 


/* SET THE COLOR FOR THE INFORMATION AND QUICK 
REFERENCE LINES (THE SCREEN BORDER) */ 

color = BROWN; 

setcolor( color. 


/* SET THE TEXT COLOR FOR INFORMATION AND QUICK 
REFERENCE TEXT */ 

foreground = WHITE; 

background = BROWN; 

settextclr( &foreground, &background ); 


/* CLEAR THE SCREEN */ 
CLEN): 
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/* WRITE THE QUICK REFERENCE COMMANDS */ 
E — 10.0; 

yl = 3.0; 

merteurabs( &xl, &yl ); 

strcpy( message, "F1 HELP SECHER .) ; 
text( message ); 


/* VIEWPORT COORDINATES */ 
x1=0.0; 

y1=0.04; 

x2=1.0; 

y2=0.96; 


/* SET COLOR FOR THE VIEWPORT */ 
border = BROWN; 
background = WHITE; 


/* SET THE VIEWPORT */ 
setviewport( &x1,&y1,&x2,&y2,&border, &background ); 
E END INITDISPLAY */ 


/* GETS THE SYSTEM GRAPHICS DEVICE FROM THE USER */ 


pewect device( device name, mode) 
si ir device name[13]; 
int *mode; 
{ 
/* IBM CGA CARD */ 


static char devicel[] = "HALOIBM.DEV"; 

/* GENERIC CGA CARD */ 

static char device2[] = "HALOIBMG.DEV"; 
/* IBM EGA CARD */ 

static char device3[] = "HALOIBME.DEV"; 
/* SIGMA DESIGNS 400 EGA CARD */ 

static char device4[] = "HALOSIGM.DEV"; 


int device; 


do 1 
/* WRITE THE POSSIBLE GRAPHICS DEVICE OPTIONS */ 
errser!(); 
geroy 19, E 


rit f ( 

"which graphics device do you have installed:" ); 
060, (418, 3); 
printf 

" 1. IBM Color Graphics Adapter (CGA)" ); 

obest 19, 9); 
put" 2. IBM CGA Compatible" ); 
seco 18, 10°); 
PE El 

A Saa IBM Enhanced Graphics Adapter (EGA)" ); 
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JOTO (3 7.: 


print £ m" 4. Sigma Designs Color Zune 
gotozxV (87 14 ); 

Prince t O Selection" E 

/* GET THE USER'S INPUT */ 

device = getche(); 

} while ( device < 49 || device > 52 ); 


CTS SEE 1 Js 


switch ( device |) 


t 
/* GET THE NAME OF THE GRAPHICS DEVICE DRIVER 


case 49: 
strcpy( device name, devicel ); 
*mode - 1; 
break; 

case 50: 
strcpy( device name, device2 ); 
“mode, 1; 
break; 

Case ie 
strcpy( device name, device3 ); 
*mode = 4; 
break, 

case 52: 


strcpy( device name, device4007 
*mode = 3; 
break; 


) 
) /* END SELECT DEVICE */ 


[kkk *k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k ke k k k k k k k k x x 


END INITDISP.H 


Kk k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k / 
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f K Kk kk kk ke ke kk kk kk ke ke Sk k k k X Kk k Xk k k X k xk Kk k x k k k k xk k k k k k k xk k Kk k k % x x 3% ok 


M HEADER FILE: HELP.H * 
* WRITTEN BY: MARVIN A. WYANT, JR. Š 
DM TESORO BAST MODIFICATION: 12 MARCH 1988 S 
EENPUREOSE: TO DISPLAY A HELP MENU À 


EEK AKKU I OR KK OK UK KK k k k k k k k k k k K K K K K K k x x X x x / 


/* DISPLAY THE HELP MENU */ 


help() 
( 
/* AN ARRAY TO HOLD THE CONTENTS OF THE SCRREN 
COVERED BY THE HELP MENU */ 
extern int window array[30000]; 
Blade x2, X97 x4; 
A E v2, y3, VA; 
Bnteborder; 
int Dackground; 
int mode; 


DCFG, 

/* AREA OF THE SCREEN TO BE SAVED */ 
Eas 

v0 2383.0; 

x2 = 639.0; 

y2 = 184.0; 


/* SAVE THE CURRENT SCREEN CONTENTS */ 
movefrom( 6x1, &yl, &x2, &y2, window array ); 


/* SET COLORS FOR MENU VIEWPORT */ 
border = NOTHING; 
background = BLACK; 


/* MENU VIEWPORT COORDINATES */ 


Soon 0:0; 
v3 = 0.04; 
x4 = 1.0; 
y4 = 0.518; 


/* SET THE VIEWPORT FOR THE MENU */ 
setviewport ( &x3, &y3, &x4, &y4, &border, 
background; 


/* DRAW A BOX FOR DISPLAYING THE TEXT WITHIN s 
border = WHITE; 
setcolor (&border); 


x3 = 4.0; 
23 375.0; 
x4 = 634.0; 
y4 = 9.0; 


box(&x3,&y3,&x4,&y4); 
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/* WRITE MENU TEXT */ 
Gotoxy (20m 
print s HEEPEMENUM): 
gotoxy 72) 


Printer ("Tiere He CEGE 
gotoxy 51 

print i EO ee DEMOS 
goto c E 

printf("FlO0 .... RETURN TO DOS 


g6texy (30,172); 
princi ("< ESC- TEOT EXIT: 


/* EXIT FROM THE MENU */ 
do í 
q — getrch 
if ( g == 27 ) 
{ 
/* COORDINATES FOR SYSTEM VIEWPORT */ 
x3 = 0.0; 
v3 = 0.04; 
x4 1.20: 
y4 = 0.96; 


border = NOTHING; 
background = NOTHING; 


/* RESTORE THE SYSTEM VIEWPORT */ 
setviewport ( &x3, &y3, &x4, &y4, &border, 
&background ); 


/* RESTORE SCREEN COVERED BY MENU VIEWPORT */ 
mode = 1; 
moveto( &xl, &yl, window array, &mode ); 
} 
) while (g != 27); 
) /* END HELP */ 


[ARK AA AAA AAA KARA AAA AAA AAA AAA AAA AAA AA AA AAA AAA KARA x 


END HEBEGH 


Ck kk Ck koe k k k k k k k k k k k xk k k k k k k x k k x k k k k k k k k k k k k x k k k k x ke kk ko kk kk 
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* 
* 
* 
* 


HEADER FILE: 


DRAWGEN.H 


WRITTEN BY: MARVIN A. WYANT, JR. 
12 MARCH 1988 = 


DATE OF LAST MODIFICATION: 


PURPOSE: 


* 


* 


TO DRAW A MODEL’S GENUS GRAPH Z 


O E A UNTEN NEN RI UNI RK KK RK Kk k k k k K k kK X Xk X K k k x / 


/* DRAW THE GENUS GRAPH */ 


alfa” genus (relptr, posptr, temptr) 
/* POINTER TO RELSHIP DATA STRUCTURES */ 


FELSIIP *relptr; 


/* POINTER TO ENTITY DATA STRUCTURES */ 


ER STTZ BOSPET? 


POINTER TOMTEMPORARY ENTITY DATA STRUCTURES */ 


POSIT *temptr; 
{ 


int sizel; 

Ant Size2: 

Mal eolor; 

Ent Y 

Micmcaountl, countz; 
int level counter; 
unn pEMoopl, l00p2; 
int test; 

int compare; 
mnrEuSed array[50]; 
SEÉECPY(( relptr + l 
Serco. relptr + 1 
sem=cpy ((rtelptr + 1 
See relptr + l 
Eege relptr + 2 
Serepyi( relptr + 2 
wran relptr + 2 
Strcpy(( relptr + 2 
Serepy(( relptr + 3 
Seremall relptr + 3 
sErepy(( relptr + 3 
sSErepyWerelptr + 3 
strcpy(( relptr + 4 
strcpy(( relptr + 4 
Ssperepy(( relptr +4 
strcpy(( relptr + 4 
r Dy ((Trelptr + 3 
SeErcey (( relptr + 5 
Semeoy<( relptr + > 
Serepy(( relpter +5 
Berepy(4( relper + 6 
Serepy(( relptr +6 
Serepy((,relptr + 6 
strcpy(( relptr + 6 


Count 3. YXC6unt4, count os; 
=> êlname, "SUPPLY" ); 
)=>Teltype, "A"-); 

) -> e2name, "PLANT" ); 
) -> e2type, "PE" ); 

) -> elname, "LINK" ); 

) => eltype, "CE" ); 

) -> e2name, "PLANT" ); 
E eztv pe, VER): 

) -> elname, "LINK" ); 
eee, s CB), 

) -> e2name, "CUSTOMER" ); 
) -> e2type, "PE" ); 

) -> elname, "DEMAND" ); 
) -> eltype, "A" ); 

) -> e2name, "CUSTOMER" ); 
m e2type, "EE" ); 

) -> elname, "T:SUP" ); 
) => eltype, "T" ); 

) -> e2name, "SUPPLY" ); 
) -> e2type, "A" ); 

W= Fe lname,  "T:SUP" ); 
EE 2 ltype, "T" `); 

) -> e2name, "FLOW" ); 

) -> e2type, "VA" ); 
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strepy(( relptr + 7 ) -> elname fs EE 
strcpy (( relptr + 7 ) -> eltypo r. 
strepy(( relptr + 7 ) -> eZname, “Deke ae 
strcpy(([ relptr + 7 ) -> e2type, Auer 
strcpy(( relptr + 8 ) -> elname; DER = 
strcpy(([ relptr + 8 ) -> eltype aw 
strepy(( relptr + 8 ) -> e2name "LINK" DE 
strepy(( relptr + 8 ) -^ e2type =- 
strepy(( relptr + 9 ) -» elname, "TOT COSQUEE 
strepy(( relptr + 9 ) -> eltype, "E" y; 
strcpy (( relptr + 9) -> eZnamem cos. 
strcpy (( relptr + 9 ) =>" e20/pe zur E 
strcpy(( relptr + 10.) => elnamem r reo E 
strepy(( relptr + 10 ) -> eltype url 
strcpy(( relptr + 10 ) Zr e2Znamem Eo =" 
strepy(( relptr + 10 ) -> e2type, "vao pp 
strcpy(( relptr + 11 ) -> elname, “TF: DEMAND wie 
strcpy(( relptr + 11 ) ele. pe E 
strcpy(( relptr + 11 ) -» e2name; “FLOW EEE 
strcepy(( reiper + 11) => ée2type s 
strcpy(( relptr + 12 ) => elname, "T: DEMAND EE 
strcpy(( relptr $0542 ) -> eltypc p s n 
strcpy(( relptr + 12 ) => e2name, "DEMAND" ); 
strepy(( relper + 122 )7 2 27e2type a = 

sizel = 12; 

count Lw=J0 

count2. 0: 

level count cr -= 


/* FIND ALL THE PRIMITIVE ENTITIES AND PLACE ON LEVEL 


ONE */ 
for ( loopl = 1; loopl <= sizel; “loop occ p 
{ 
compare — strcmp(( relptr + loopl))) => eZztypen 
"BEN 
if ( compare == 0 ) 
{ 
countl = coupe- 
strcpy(( posptr + come mame 
( relptr + loopl ) -> e2name 
strcpy(( posptr + countl Der 
( relptr * loopl ) -> es 
( posptr + countl ) -> level = level counter; 
used array[loopl] = 0; 


} 


count4 = count: 
count3 = counti: 
count5 = T, 
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/* GET REMAINDER OF MODEL ELEMENTS AND PLACE ON 
APPROPRIATE LEVELS */ 


do { 
test = 1; 
I "counter —Jevelsecounter +' 1; 
REM Sos] ="Count5; ]oopl <= count3; 
1505 8 oo +L) 
{ 
for (gl 92-11 ]oop2 <= sizel; 
loop2 = loop2 + 1) 
{ 
compare = strcmp( 
( relptr + loop2 ) -> e2name, 
(ees ler r. LOOP) name; 
if ( compare == 0 ) 
{ 
Count =meountZ +. l 
Pedra ra o002 | = 1; 
count4 = countl -* count2; 
Strepy (( = Pespes s+ couned =- -= name, 
( relptr + loop2 ) -> elname ); 
SELEDy | (Fposptr+ Count JM. Tepe. 
( relptr F loop? Mi= > “ele per 
DOSH counti -=> 
level ="T1evellfkRs lsusui3srn  teeÑ]Çí#F 
) 
) 
) 
/* TEST TO SEE IF ALL MODEL ELEMENTS HAVE BEEN 
ASSIGNED LEVELS */ 
former — 1, + <= sizely 1 = 1 + 1) 
{ 
if ( used array[i] == 0 ) 
( 
test = 0; 
) 
} 
CONES = count4; 
Counc — count4; 
of — countd4 - count2 +1; 
count2 = 0; 
) while ( test == 0 ); 
sıze2 = count3; 


compress array(posptr,temptr,&size2); 


/* ASSIGN ELEMENT ICONS COORDINATES */ 
get coordinates (posptr,&size2); 
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/* CLEAR THE SYSTEM WORKSPACE */ 
color = WHITE; 

setcolor( &color ); 

clr 0) 

/* DRAW THE ICONS */ 

draw icons (pesptr,size2)% 


/* DRAW THE ARCS BETWEEN ICONS */ 
draw _lines(relptr, sizel, posptr, size2), 
} /* END DRAW GENUS */ 


/* ELIMINATE DUPLICATE MODEL ELEMENTS WITHIN THE 
POSITIONING DATA STRUCTURE PF V 


compress array (posptr,temptr,size2) 

POSIT *pospt r; 

POSIT, “temper, 
int *size2; 

{ 

int Counti. 
AE COLE 
Int Loop Lt 
ine OOP 
int comparel; 
int compare2; 


countl = *size2; 
for (loopl = 1; loopl <= counti R ioo pi = 150 EI NM 
{ 
for ( loop2 = loopl + (1:0 100628 = Orn M 
loop2 2 loop2 5E 
( 


comparel = strcmp(( posptr * loopl ) => manes 
( posptr + loop2 ) -> name 
compare2 = strcmp(( posptr + loopl ) -> yume 
( posptr + loop2 ) -> ty TE 
if (( comparel == 0 ) 88 ( compare2 == 0)) 


( 
/* ASSIGN NECESSARY PLACEHOLDER ICONS */ 


if (( posptr + loopl ) -> level == 
( posptr + loop2 ) -> leve 
{ 
( posptr + loop2 ) —zTreve)# zur 
) 
else 


( 
strcpy ((posptr + loopl) => type "SAA 


countz =s 
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/* ELIMINATE UNNECESSARY MODEL ELEMENT REFERENCES */ 


Bora zeloopl 41. loopl <= countl; loopl = loopl + 1 ) 
{ 
MEM (pospt: + loopl ) -> level != 0) 
{ 
count2 Count gant; 
strcpy (( temptr + count2 ) -> name, 
(opesper + loool ) -> name ); 
strcpy (( temptr + count2.) => type, 
E OSPE + loop!) => type ); 
( temptr + count2 ) -> level = 
Uxpesptr + loopl ) => level; 
} 
} 
Or loopl ="Ccount2; l1oopl = loopl + 1 ) 
{ 
Stremiı((sposptr + loop! ) => names 
(TZtemptr +*160plr). => name ); 
Ser epy ( posptr t Loopl J -> type, 
(Meena 128510 type Y); 
Mposptr + .leoepl -> level = 
(tempti r 100p1\ ) => level; 
) 
ksize2 = count2; 
) /* END COMPRESS ARRAY */ 


/* DRAW THE ICONS */ 


hou Icons (posptr, size) 
Bost! ^posptr; 


int size; 


{ 
Ant 
int 
Pn C 
Int 
Int 
Int 
Inat 


char name[9]; 
char type[3]; 


Kool, 

comp pe; 
comp Ce; 
comp a; 
comp va; 
comp. f; 
comp t; 


tloat xpos; 
modb vpos; 


91 


/* DETERMINE THE ICON AND DRAW IT AT ITS ASSIGNED 
LOCATIONS 
for ( loopl = 1; loopl <= size, ioopl. oc ELM 
{ 


strcpy( name, ( posptr + loop = um er 
Strcpy( type, ( posptr + loop 3" P 
xpos = ( posptr + 1lo0opl ) 5 
vpos = ( posptr + loopl -PE 


comp pe = strcmp( type, "PE" ); 
comp ce = stremp( type. EEDE 
comp a = strcmp( type, "A" ); 
comp va = strempt type, uM 
comp £ = stremp( type, EEEE 
comp t — strcmp( type) VE E 


if ( comp pe -- ) 

ON xpos, ypos, name ); 
a if ( comp_ce == ) 

ina od xpos, ypos, name ); 
ix if ( comp a -- ) 

eh y xpos, ypos, name ); 
as: DE OMM LM ) 

onn dd Xpos, ypos, name ); 


} 


else if ( comp f == ) 
a: Xpos, ypos, name ); 
a E comp t == 0s) 
draut xpos, ypos, name ); 


else 


{ 


draw_space( xpos, ypos ); 


} 
} 
} /* END DRAW ICONS */ 
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/* ASSIGN THE ICON COORDINATES */ 


get coordinates( posptr, array size ) 

POSIT *posptr; 7 
ii s array Size; 

{ 

uU EE 

Ex; 

int size; 

int level size[100]; 

int max level; 

int largest level; 

Aae pic width; 

Aat extra space; 

float space width; 

jo XC ULSOr, Yeursor; 


EN. — Size, 
uo Ec IESO Sptr + size ) => level; 


/* COUNT THE NUMBER OF ICONS IN EACH 
GENUS GRAPH LEVELS */ 
kor Loopl = 1; loopl «- max level vEcopl#=> loopl +1) 
( 
level size[loopl] = 0; 


) 


mem lo oi 1; loop! <= size; loopl = loopl + 1 ) 
{ 
pa (xposptr + loopl ) -> level; 
lere] — level size[x] * 1; 


Mess level = 1; 


/* FIND THE MAXIMUM NUMBER OF ICONS ON A SINGLE 
LEVEL */ 
seo loopl <= max level — 1;loopl = loopil + 1) 
{ 
s loo. e 
if ( level size[x] » level size[loopl] ) 
{ 
EE heel = = 
} 
} 


/* DETERMINE WIDTH OF GENUS GRAPH */ 
ME ( level size[largest level] < 6 ) 
{ 
pic width = 6 * 102.0; 
} 
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else 


{ 
pic width = level size[largest level] * 102.0; 


) 


y Cul SOS ZO 


/* ASSIGN EACH ICON ITS X,Y COORDINATES */ 
for ( loopl = 1; loopl <= max level o TM 
{ 


extras patos 


pic width - ( level size|ioopi MU z 


space width = 
extra space / ( level size[loopl] + 
xcursor = space width; 
for ( loop2 = 1; loop2 <= size ioon see 
{ 


if (( posptr + loop I) 7 Tevel -cl 
{ 
( posptr + loop2 ) => xpos = EES 
( posptr + loop2 ) => ypos = yeursow, 
xcursor = xcursor + space width + 9E 
} 

} 

ycursor =MWienrsor,’r 3050 


} 
} /* END GET COORDINATES */ 
/* DRAW A LINE SEGEMENT FROM X1,Y1 TO X2,Y2 */ 


Jine from( xl; yl) sm 
[lO3b xl. vi, OO EDD 
{ 
int lot: 
float xstart, ystart, xend, yent 


start. = Poe T 7160: 
vstapb <= yl + 50407 
xend = x2 + 17.0; 
yend = y2; 


color = BLACK; 
setcolor (color 


movabs( &xstart, &ystart ); 


lnabs( &xend, &yend ); 
) /* END LINE FROM */ 
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/* DRAW RELATIONSHIP LINES */ 


draw lines( relptr, sizegen, posptr, sizepos ) 
RELSHP *relptr; 
int sizegen; 
EOS TTT *posptr; 
int sizepos; 
{ 
ME OODL, loop2, loops; 
int compare; 
int base level; 
Mle diff; 
ied cl. yl, x2, y2; 
Shar start name[9]; 
char end name[9]; 


/* DETERMINE ICONS FOR LINE TO BE DRAWN BETWEEN */ 
er (ioopl = 1; loopl <=@saizegen; loopl = loopi + 1 ) 
{ 
strepy(start name, ( relptr + loopl ) -> e2name); 
Serepyı end name, (relptr + loopl ) => elname ); 
fer (Toop2 = 1;100p2 <= Sizepos;loop2 = loop2 + 1) 
{ 


comparer = SETeEMp( Stare name, 
( pospen 7 loopZ) ))—— name); 
1f( compare == 0) 
{ 
Fo ce Posper a i loop) — eve; 
iw "(DOSE met a LOOD2.)) => XPOS; 
Die DOS Er 210027) => ypos; 


Eorp = l oop ti OOD Ss<— s12eposr 
loop? = Toop A 
{ 


compare = strcmp( end name, 
(M posptr t loops ) -> name ); 
if ( compare == 0) 
{ 
EE EE + loop3 ) => level - base level; 


/* DRAW LINES BETWEEN CONSECUTIVE LEVELS */ 
if ( lev diff -- 1) 

{ 

O POSPEE UL Loop) -> xpos; 

DOS per EE ) —> ypos; 

Binet roi Vl, 22,32), 

} 


215 


/* DRAW LINES PASSING THROUGH LEVELS */ 
else lev ditt "20 
{ 


al EZ 
yl = y2; 
x2 = ( posptr + loop3 ) SS E 


y2 = ( posptr + loop DA ee 
line from( xl, yl, 22 75: 


} 


} 
} /* DRAW LINES */ 


J k k k k k k k k k k k k k k k k k Kk k k k k k k k k k k k k k k k k k k k x k ke k x X x X x K x x x ke ke kk kk 


END DRAWGEN.H 


kx kkk k k k k k k k k k k k k k k K k k k k k K Kk K K K K k U K K K K K K ke K K k x K x ke kk kk kk kk kx f 
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E. 


APPENDIX C 


GUIDE TO USING THE GRAPHICAL USER INTERFACE PROGRAM 


The following steps are required to use the graphical 
user interface program: 


Copy the graphical user interface program (MMS.EXE) to 
the directory containing the ORACLE DBMS. 


Load the ORACLE DBMS into extended memory. 


— When in 


the ORACLE directory, type 'ORACLE'. 


Begin execution of the program by typing 'MMS'. 


A menu for selecting the graphics device installed in 
your machine now appears on the monitor. Enter the 
number corresponding to the graphics device installed 
in your machine. 


The system screen now appears on the screen. Several 
options are available at this point. 


a. Press 


De Press 


eM Press 
genus 


- Use 


Fl to display the help screen. 
F2 to draw the genus graph. 


F3 to display model element paragraphs (the 
graph must first be drawn). 


the cursor keys to position the graphics 


cursor over the desired model element. 


- Press enter to display the paragraph information. 


lus Press 


F10 to exit the program. 


SR 


IEU 
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